Sorry about the delay, but here's my follow-up, as promised. I'll break your reply down to the core questions/concerns, for brevity's sake.
I think in light of basic auth, digest auth looks more like fort knox -bcrypt would be fort nox; MD5 (digest uses it exclusively https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#digest) is the cryptographic equivalent of a bridge made of straws (way too fast and not salted) -"The original author of the MD5 password hash algorithm has publicly declared his software end-of-life and is "no longer considered safe" to use on commercial websites." June 2012 http://www.zdnet.com/article/md5-password-scrambler-no-longer-safe/ (sources should be linked throughout the article)
TLS only addresses "end-to-end" encryption, but does not protect you from host-related threats. -If this is truly your primary concern, you should be writing your own authentication mechanism to address the security gap (or forgo passwords http://www.cnet.com/news/google-security-exec-passwords-are-dead/). Digest's approach to only transfer and store hashes seems ideal, but it utilizes a weak hashing algorithm. Basic supports the strongest hashing algorithms, but decrypts the TLS packets before hashing and verifying the password. Basic is considered the "go to" because out of the two, stored MD5 passwords are a bigger surface for attack than user passwords stored in memory for fractions of a second (sys admins are legally bound, and you should be seriously considering other countermeasures if you think a hacker might be able to gain access to your system memory. See: SELinux).
The number of ways to break TLS connections is growing -I'm not sure whether to say this statement is redundant or false; an updated system is really only vulnerable to zero-day exploits. While zero-days should be considered during planning, we're actually talking about a general security compromise with digest (even if it includes a shift in the attack vector), so I'm going to say this point is moot in the context of digest as a solution (and in light of what I've shared above).
Are you trying to say that Digest Auth is "unnecessarily increasing complexity/server load"? -Yes. Especially because it actually has security drawbacks (like limiting the hashing algorithm you store passwords with).
Other considerations -exploitable via a Man-in-the-Middle attack. https://tools.ietf.org/html/rfc2617 (refer to section 4.8) -though rfc2617 also added a number of security options, a number of them are purely optional (you'll want to read through the above link for more detail on which features this affects) -based on your concerns, you should really check out that cnet article and consider implementing soft-tokens in place of passwords. They're more secure, and in the event of a compromise, they're unique and disposable.
Hopefully this is digestible (unintentional pun). I'll try to answer any other questions you have, but I'm not sure I'll have the time/energy for another email this long so you may have to keep it to a couple more straightforward questions.
--- Colin Purcell | IT Administrator
On 2016-04-05 5:59 am, Tobias Mueller wrote:
Hi.
On Mo, 2016-04-04 at 19:07 -0400, Colin Purcell wrote:
digest is widely accepted as laughably weak
Do you have any references for your claim?
I think in light of basic auth, digest auth looks more like fort knox. So it seems only logical to prefer digest auth over basic auth whenever possible. InfCloud claims that it is not compatible, but I haven't seen any instance of such an incompatibility. The documentation also lacks pointers to said incompatibilities.
My hypothesis is that such incompatibilities do not exist. In fact, I'm using (admittedly an older version of) CalDAVMate successfully with Firefox and Baikal configured to do digest auth.
For now, it seems to me that digest auth is advised against without any substantiation. I would like to understand why basic auth is preferred over digest auth.
and thus a generally unnecessary layer when the entire session (including the authentication process) is already secured via SSL or TLS.
Fair enough, but that's not the argument that InfCloud brought up. The argument there seems to be "Lot of browsers have wrong or buggy digest auth support (especially if used from JavaScript)".
Also, I think it's wrong. I agree that TLS solves many problems. But it doesn't solve all problems that digest auth addresses.
TLS is not used for client authentication. Nobody does, unfortunately. So TLS is only used for preventing someone on the wire to mess with your packets.
But there are more threats than that. You may not want your credentials to leak to a curious sysadmin, anyone stealing the credentials stored on the server, or a broken client implementation of your protocol. And mind you, things tend to be more broken than we think. The number of ways to break TLS connections is growing.
So even if you think that TLS solves all of your problems, some people find it valuable to have a second line of defence. But you recommend against it with no good cause, from what I have understood so far.
I would compare Digest Authentication to requiring a second password for login
I think this comparison is very flawed. If only because with digest auth, you don't leak your credentials in plain text to anyone who is able to get their hands on your traffic. So the additional security is very much unlike a second password.
you're much better off to increase the length of the original password (key length for our purposes) or explore other avenues of security that don't unnecessarily increase complexity/server load (one-time passwords maybe? The world is your oyster).
Are you trying to say that Digest Auth is "unnecessarily increasing complexity/server load"?
I agree with the sentiment of your example: It's about making the cost of an attack much more expensive than defending against them.
And this is exactly why I don't understand that digest auth is frowned upon. From what I can tell it's well supported in both servers and clients. It costs a round trip and a few hashes. Sure, that's much more expensive than basic auth, but the attack is much much more expensive. Unless you convince me that it's "laughably weak", I maintain the proposition that digest auth provides more value than basic auth. And I think it's very easy to see. Even when using TLS. Combined with what I consider low cost (modulo the yet to see incompatibilities which would weigh a lot), I don't see how you could possibly conclude to advise against digest auth.
If you're genuinely interested in the topic, I'd be happy to elaborate on anything unclear.
Looking forward to reading.
Cheers, Tobi
Hi.
On Mo, 2016-04-11 at 01:05 -0400, Colin Purcell wrote:
I think in light of basic auth, digest auth looks more like fort knox -bcrypt would be fort nox; MD5 (digest uses it exclusively https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#dige st) is the cryptographic equivalent of a bridge made of straws (way too fast and not salted)
So you're making the point that Digest Auth makes use of MD5 and that this is a weak algorithm. Thus, and this is me interpreting your statement, Digest Auth must be weak.
-"The original author of the MD5 password hash algorithm has publicly declared his software end-of-life and is "no longer considered safe" to use on commercial websites." June 2012 http://www.zdnet.com/article/md5-password-scrambler-no-longer-safe/%C2%A0 (sources should be linked throughout the article)
TLS only addresses "end-to-end" encryption, but does not protect you from host-related threats. -If this is truly your primary concern, you should be writing your own authentication mechanism to address the security gap (or forgo passwords http://www.cnet.com/news/google-security-exec-passwords-are-dead/).%C2%A0 Digest's approach to only transfer and store hashes seems ideal, but it utilizes a weak hashing algorithm. Basic supports the strongest hashing algorithms, but decrypts the TLS packets before hashing and verifying the password. Basic is considered the "go to" because out of the two, stored MD5 passwords are a bigger surface for attack than user passwords stored in memory for fractions of a second
Again, I only see the point of MD5 being a weak algorithm.
The number of ways to break TLS connections is growing -I'm not sure whether to say this statement is redundant or false; an updated system is really only vulnerable to zero-day exploits. While zero-days should be considered during planning, we're actually talking about a general security compromise with digest (even if it includes a shift in the attack vector), so I'm going to say this point is moot in the context of digest as a solution (and in light of what I've shared above).
Again, your point is that MD5 is a weak algorithm.
Are you trying to say that Digest Auth is "unnecessarily increasing complexity/server load"? -Yes. Especially because it actually has security drawbacks (like limiting the hashing algorithm you store passwords with).
The additional load is a few hashes per request. As you've mentioned, MD5 is relatively fast. So yes, it is additional load. But it's a few hundred CPU cycles.
How much additional security you think you get when employing Digest Auth over Basic Auth? I have the impression you claim it's zero. I claim it's greater than zero. Maybe not much. But the additional value is greater than the investment I have to make.
How much more security would you want to have in order to accept that few hundred cycles as a good investment?
Would you recommend using Digest Auth over Basic Auth if another hash algorithm was used? What if it turned out that the use of MD5 in Digest Auth is not affecting security; Would you then consider it to better than Basic Auth?
Even if MD5 can be broken relatively easily, your attacker has to invest a lot more than if you were using Basic Auth in order to get hold of your credentials. Much more than the few hundred cycles I have to invest.
Other considerations -exploitable via a Man-in-the-Middle attack. https://tools.ietf.org/html/rfc2617 (refer to section 4.8)
Sure. As is Basic Auth. So if you are rejecting Digest Auth because it doesn't authenticate the other end, then you also have to reject Basic Auth.
-based on your concerns, you should really check out that cnet article and consider implementing soft-tokens in place of passwords. They're more secure, and in the event of a compromise, they're unique and disposable.
Fair enough. We can easily agree that in an ideal world, we could use all sorts of standardised and not standardised things. But in reality, we only have so many mechanisms to choose from. And in our very scenario, I can either chose to use Basic Auth or Digest Auth. Soft-tokens, unfortunately, do not play a role in my reality. Mostly because of the lack of easily consumable implementations. And the core question here has always been: In light of the available choices (Basic Auth or Digest Auth), which makes the best recommendation?
I think that recommending Basic Auth is just wrong and is terrible security advice. Of course, the Internet Explorer issue is a very valid concern. But in this subthread we're not talking about that.
I should add that although MD5 is cryptographically broken, it can still be used for certain constructions. For example, the MAC used in TLS employs MD5. For all I know, HMAC-MD5 is also considered to be good to use. And I have yet to hear that the use of MD5 breaks Digest Auth. But *even then*, the attacker would have to launch a much more expensive attack than if I used Basic Auth.
Cheers, Tobi
**I'm sure the inf-it admins are sick of this thread by now, so I'll apologize now for feeding the beast.
And I'm sorry if I previously diluted my point: with the use of MD5 hashing algorithm for password storage (eg. digest), a malicious user can dump your entire password DB and determine all of your user's passwords in a reasonable (often short) amount of time; this wouldn't be true if you were using basic auth and a backend that supports bcrypt.
--- Colin Purcell | IT Administrator
On 2016-04-20 5:26 pm, Tobias Mueller wrote:
Hi.
On Mo, 2016-04-11 at 01:05 -0400, Colin Purcell wrote:
I think in light of basic auth, digest auth looks more like fort knox -bcrypt would be fort nox; MD5 (digest uses it exclusively https://httpd.apache.org/docs/2.4/misc/password_encryptions.html#dige st) is the cryptographic equivalent of a bridge made of straws (way too fast and not salted)
So you're making the point that Digest Auth makes use of MD5 and that this is a weak algorithm. Thus, and this is me interpreting your statement, Digest Auth must be weak.
-"The original author of the MD5 password hash algorithm has publicly declared his software end-of-life and is "no longer considered safe" to use on commercial websites." June 2012 http://www.zdnet.com/article/md5-password-scrambler-no-longer-safe/%C2%A0 (sources should be linked throughout the article)
TLS only addresses "end-to-end" encryption, but does not protect you from host-related threats. -If this is truly your primary concern, you should be writing your own authentication mechanism to address the security gap (or forgo passwords http://www.cnet.com/news/google-security-exec-passwords-are-dead/).%C2%A0 Digest's approach to only transfer and store hashes seems ideal, but it utilizes a weak hashing algorithm. Basic supports the strongest hashing algorithms, but decrypts the TLS packets before hashing and verifying the password. Basic is considered the "go to" because out of the two, stored MD5 passwords are a bigger surface for attack than user passwords stored in memory for fractions of a second
Again, I only see the point of MD5 being a weak algorithm.
The number of ways to break TLS connections is growing -I'm not sure whether to say this statement is redundant or false; an updated system is really only vulnerable to zero-day exploits. While zero-days should be considered during planning, we're actually talking about a general security compromise with digest (even if it includes a shift in the attack vector), so I'm going to say this point is moot in the context of digest as a solution (and in light of what I've shared above).
Again, your point is that MD5 is a weak algorithm.
Are you trying to say that Digest Auth is "unnecessarily increasing complexity/server load"? -Yes. Especially because it actually has security drawbacks (like limiting the hashing algorithm you store passwords with).
The additional load is a few hashes per request. As you've mentioned, MD5 is relatively fast. So yes, it is additional load. But it's a few hundred CPU cycles.
How much additional security you think you get when employing Digest Auth over Basic Auth? I have the impression you claim it's zero. I claim it's greater than zero. Maybe not much. But the additional value is greater than the investment I have to make.
How much more security would you want to have in order to accept that few hundred cycles as a good investment?
Would you recommend using Digest Auth over Basic Auth if another hash algorithm was used? What if it turned out that the use of MD5 in Digest Auth is not affecting security; Would you then consider it to better than Basic Auth?
Even if MD5 can be broken relatively easily, your attacker has to invest a lot more than if you were using Basic Auth in order to get hold of your credentials. Much more than the few hundred cycles I have to invest.
Other considerations -exploitable via a Man-in-the-Middle attack. https://tools.ietf.org/html/rfc2617 (refer to section 4.8)
Sure. As is Basic Auth. So if you are rejecting Digest Auth because it doesn't authenticate the other end, then you also have to reject Basic Auth.
-based on your concerns, you should really check out that cnet article and consider implementing soft-tokens in place of passwords. They're more secure, and in the event of a compromise, they're unique and disposable.
Fair enough. We can easily agree that in an ideal world, we could use all sorts of standardised and not standardised things. But in reality, we only have so many mechanisms to choose from. And in our very scenario, I can either chose to use Basic Auth or Digest Auth. Soft-tokens, unfortunately, do not play a role in my reality. Mostly because of the lack of easily consumable implementations. And the core question here has always been: In light of the available choices (Basic Auth or Digest Auth), which makes the best recommendation?
I think that recommending Basic Auth is just wrong and is terrible security advice. Of course, the Internet Explorer issue is a very valid concern. But in this subthread we're not talking about that.
I should add that although MD5 is cryptographically broken, it can still be used for certain constructions. For example, the MAC used in TLS employs MD5. For all I know, HMAC-MD5 is also considered to be good to use. And I have yet to hear that the use of MD5 breaks Digest Auth. But *even then*, the attacker would have to launch a much more expensive attack than if I used Basic Auth.
Cheers, Tobi
-
Colin Purcell -
Tobias Mueller