12

The successor of RFC 2617 adds support for SHA-256 instead of MD5 and makes the qop field mandatory thus making the whole authentication more secure.

However, no major browser/client (Edge, FF, Chrome, Opera, curl) supports it.

That is a bit strange to me since usually, browser vendors are quite active when it comes to better security standards.

Why is this? Am I missing something here?

Improve this question

3 Answers 3

Reset to default
12

Most sites don't use any of the HTTP authentication mechanism, i.e. Basic Authentication or MD5 based Digest Authentication, because these mechanisms are very limited in what they offer. It is not even possible to logout using these authentication mechanisms.

But even the few sites which use HTTP authentication usually prefer basic authentication over HTTPS instead of digest authentication, since the last one requires that the passwords are stored at the server as plain text or equivalent, which of course is bad from a security perspective.

Thus the only advantage digest authentication has against other authentication forms is if is used with unencrypted connections. In all other cases it is worse than the other established ways of authentication. But, any kind of login over insecure connections is considered bad anyway today. Therefore there is no need to slightly improve an already bad authentication mechanism without addressing the basic problems of it, i.e. the necessary plain text (or plain text equivalent) storage of the password.

Apart from that the weaknesses of MD5 like a bad resistance against collision attacks and pre-image attack don't really affect its use in Digest authentication, i.e. it is still suitable for this use case when used together with a proper random server defined nonce.

Improve this answer
7
  • 3
    "requires that the passwords are stored at the server as plain text or equivalent" that's incorrect. "The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). This allows some implementations (e.g. JBoss[3]) to store HA1 rather than the cleartext password". I've used Digest a lot and it's a pity that industry interests would rather push through HTTPS & JWT/Basic auth which requires complex set ups.
    – ScalaWilliam
    Jun 4, 2017 at 22:45
  • 4
    @ScalaWilliam: To cite myself: ... stored at the server as plain text or equivalent. It is enough for the attacker to know HA1 in order to successfully authenticate which means that HA1 can be considered a password equivalent. There is no need for the attacker to reverse HA1 to get to the password because he can use HA1 directly.
    – Steffen Ullrich
    Jun 5, 2017 at 4:47
  • I still does not agree, that storing HA1 is an equivalent of storing plain text. Obtaining HA1 allows an attacker to login to this very site only. While obtaining the password itself will potentially allow an attacker to access not only this site but other sites, where user uses the same or similar password. Also, in the HA1, the site can force invalidate logins (if the breach is discovered) by changing the realm.
    – Alex Che
    Jun 23, 2020 at 13:16
  • For me, the 'we use SSL anyway' mantra is still a bad excuse for not using more secure authentication scheme. Putting all your eggs in one basket was never a good idea. While implementing the newer RFC is not such a big work for browser developers, IMHO.
    – Alex Che
    Jun 23, 2020 at 13:33
  • 1
    @AlexChe: You are right in that HA1 is better than storing the plain password. It is much worse than a properly hashed password though since HA1 does not use a random salt and uses a fast hash. And while the realm can be reset if the site is compromised this also means that users can no longer login since their passwords are no longer valid. And I agree that HTTPS should not be an excuse for not using better password methods - but it should not be used with worse password transport methods. SRP instead of Digest Auth would be a better option.
    – Steffen Ullrich
    Jun 23, 2020 at 13:39
3

That is a great find, I was not aware of HTTP Digest with SHA hashing

HTTP Digest is great because:

  • it is simple to set up [1]
  • the hash method is officially documented
  • you never need to store the user's password, just the 'H(A1)' [3].
  • thus you cannot screw it up

HTTPS+Basic auth is not so great:

  • proper set up is hard and costly [2]
  • barrier to entry for newbies, who end up having to rely on SSL providers
  • centralised, can enable undetectable snooping by rogue CA
  • provides a false sense of security
  • no general guidance of how to store credentials securely

Potential reason is that they want to consolidate control of the web, since SSL certificate issuance is centralised.

If you want the best security use HTTPS AND HTTP Digest at the same time. And DO encourage vendors to implement the latest RFC.

Improve this answer
5
  • 1
    Essentially your answer to the question is contained only in one sentence and is more like a conspiracy theory: "...they want to consolidate control of the web,...". The rest is arguing that Digest Auth is better than Basic Auth - which was not asked in the question.
    – Steffen Ullrich
    Jun 5, 2017 at 5:05
  • Apart from that "you cannot screw it up" and "you never need to store the user's password" is misleading since even if only the stored H(A1) is known to the attacker it is enough to successfully authenticate. This is very different from proper password storage usable with Basic Auth where knowledge of the stored password hash is not enough for successful authentication.
    – Steffen Ullrich
    Jun 5, 2017 at 5:06
  • 2
    I though I was the only paranoid around, but on a serious note what stops any rogue party either from the government or any organization to infiltrate any CA or browser developer, OS developer or hardware manufacturer? I guess it makes sense to use both at least to make their job harder, but in any case you should always use SSL.
    – jigzat
    Nov 7, 2017 at 17:21
  • Exactly @Jigzat, SSL is actually fairly weak.
    – ScalaWilliam
    Nov 10, 2017 at 8:01
  • 1
    Also, SSL is not always possible. Take devices like routers or modems as an example.
    – Alex Che
    Jun 23, 2020 at 13:35
1

I am going to approach this question specifically from the perspective of "why is RFC 7616 not much better than RFC 2617":

  1. A simple cryptographic hash, no matter the strength of the algorithm, is insufficient to protect a password against offline attacks. This is the space of key derivation functions, like PBKDF2, bcrypt, scrypt, and Argon2. At the very least, the password should be salted before hashing. So, even using the most secure options RFC 7616 allows, and with an eye to writing the most secure implementation possible, at the end of the day the server would still have to store a simple, unsalted hash of the password. That's barely better than storing the password itself.
  2. There is no signature or MAC and thus no integrity protection. If you look at how AWS authenticates REST requests you will see that they require the construction of an HMAC from important request parameters and a hash of the body content. This mechanism has its own faults for other applications (it's only using MD5 to hash the content and the secret key is used directly instead of being fed through a KDF) but it at least provides a moderate level of integrity protection. Since RFC 7616 lacks such a mechanism, if you were using insecure transport (plain HTTP) and someone could intercept and modify packets (man-in-the-middle) then they could replace your actual request with one of their choosing.

You can solve problem 2 by using HTTPS or other secure transport but you can't solve problem 1 because it's fundamental to what the specification requires.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .