And the HA1 cannot be stored hashed, because it is used in a second hash involving the expiry time

👍

@damienalexandre given the importance of this change, could you please add a comment about your downvote? Is this authentication something that you or your company or some project you know need? Thanks!

👍, it may cause some interoperability issues with legacy systems, but the modern web must use HTTPS and not this kind of strategies.

@javiereguiluz just removed my 👎 because I read too fast and mixed up HTTP Basic and HTTP Digest 😋 😬

👍

See #24335

It would be great to explain to security audit firm why Basic Authentication is better. On the last project that have been audited they considered that HTTP Basic needed to be changed to Digest...

Even if you arguments are exact and understood from technical guys it can be disturbing for Project Managers or other people that just read this kind of articles: https://en.wikipedia.org/wiki/Digest_access_authentication

I think it would be important to document the fact that Basic used with Bcrypt is better and illustrate with an example as a best practice.

I think it would be important to document the fact that Basic used with Bcrypt is better and illustrate with an example as a best practice.

In HTTP (without HTTPS), Digest is better. But with Let's Encrypt and CloudFlare, there is no point using Digest anymore.

@raziel057 the way Digest works forces you to store the password or the HA1 in clear. A leak of them allows to forge a valid digest auth (if the HA1 is stored, it would require a custom client side implementation as browsers are taking the password as input and compute a HA1, but attackers can afford this, especially given that this may simply mean using a custom build of their browser changing the digest auth to bypass the HA1 computation itself and treat the input as HA1 directly).
Security audit firms should not accept a storage in clear, meaning they should not consider Digest auth as acceptable.

HTTP Basic over HTTP is indeed not safe against MitM, but the same argument applies for form login (which is why browsers are pushing towards HTTPS btw)

@stof Thanks for your explanations which could be used as a reply for Security Auditors. In my case it was obviously authentication over HTTPS.

I know this is a rather old conversation. Nevertheless, I came across the need for Digest authentication in my SmartHome automation project. Some control devices (wifi switches, heating control units) still require this authentication scheme and updates on their side are not to be expected. As the symfony software component is only communicating with these devices over a secure home network, there are no security concerns to be taken into account. Is there a way to re-include the client-side DigestAuthenticationListener again, maybe in the form of a plugin?

Yes you can easily create a plugin ("bundle") for that: https://symfony.com/doc/current/security/custom_authenticator.html