8

If the DIGEST-MD5 negotiation is done over an HTTPS connection instead of HTTP, does that prevent this list of disadvantages from Wikipedia?:

Digest access authentication is intended as a security trade-off. It is intended to replace unencrypted HTTP basic access authentication. It is not, however, intended to replace strong authentication protocols, such as public-key or Kerberos authentication.

In terms of security, there are several drawbacks with digest access authentication:

  • Many of the security options in RFC 2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC 2069 mode.

  • Digest access authentication is vulnerable to a man-in-the-middle (MitM) attack. For example, a MitM attacker could tell clients to use basic access authentication or legacy RFC2069 digest access authentication mode. To extend this further, digest access authentication provides no mechanism for clients to verify the server's identity.

  • Some servers require passwords to be stored using reversible encryption. However, it is possible to instead store the digested value of the username, realm, and password.[2]

Similar to: Is BASIC-Auth secure if done over HTTPS?

Community
  • 1
Charles Offenbacher
  • 255
  • 3
  • 6

2 Answers2

7

Digest access authentication is intended as a security trade-off. It is intended to replace unencrypted HTTP basic access authentication. It is not, however, intended to replace strong authentication protocols, such as public-key or Kerberos authentication.

By implementing SSL you are bringing public-key authentication into the equation so you are addressing that issue. Anything stronger than that would require additional infrastructure that wouldn't be practical in many situations.

Many of the security options in RFC 2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC 2069 mode.

That has to do with implementation and really doesn't apply here.

Digest access authentication is vulnerable to a man-in-the-middle (MitM) attack. For example, a MitM attacker could tell clients to use basic access authentication or legacy RFC2069 digest access authentication mode. To extend this further, digest access authentication provides no mechanism for clients to verify the server's identity.

Using SSL will greatly reduce the risk of MITM attacks. It will provide the method for verifying the server's identity. Yes a certificate can be spoofed, but web browsers are getting better at alerting users to these issues.

Some servers require passwords to be stored using reversible encryption. However, it is possible to instead store the digested value of the username, realm, and password.[2]

Yeah you shouldn't be doing that anyway.

So the answer is yes, SSL does address the weaknesses quite well. It isn't perfect but the next step after that is a pretty big one.

Mark Burnett
  • 2,810
  • 13
  • 16
  • 2
    What are you referring to here -- It isn't perfect but the next step after that is a pretty big one. – pkrish May 06 '15 at 16:53
-1

It will prevent issues during transit, sure, but what about on the servers themselves? Why not just use SHA-1/2?

Numpty
  • 129
  • 3
  • "MD5" makes me look out too because of the well-known collision attacks, but DIGEST-MD5 hasn't been shown to have any issues and is a SASL / Jabber standard (for instance, Facebook uses it as a fallback for their chat authentication). So in this case, SHA-1/2 don't offer any advantages because DIGEST-MD5 is fine, and they're not supported on the 3rd party we're authenticating against. – Charles Offenbacher Mar 28 '12 at 21:07
  • 1
    Definitely zoned in on the "MD5", didn't even see the DIGEST infront of it. Was before the coffee kicked in :) – Numpty Mar 28 '12 at 23:10