7

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?

8

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.

  • 1
    "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. – Scala William Jun 4 '17 at 22:45
  • 2
    @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 '17 at 4:47
2

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.

  • 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 '17 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 '17 at 5:06
  • 1
    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 '17 at 17:21
  • Exactly @Jigzat, SSL is actually fairly weak. – Scala William Nov 10 '17 at 8:01

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.