[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Inf-IT DAVcl] Blank page,with Internet Explorer


**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/ ;
(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 
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

References:
[Inf-IT DAVcl] Fwd: Blank page,with Internet ExplorerAdmin - Muskoka Auto Parts Limited <admin@xxxxxxxxxxxxxxx>
Re: [Inf-IT DAVcl] Blank page,with Internet ExplorerJán Máté <jan.mate@xxxxxxxxxx>
Re: [Inf-IT DAVcl] Blank page,with Internet ExplorerTobias Mueller <muelli@xxxxxxxxxxxxxx>
Re: [Inf-IT DAVcl] Blank page,with Internet ExplorerJán Máté <jan.mate@xxxxxxxxxx>
Re: [Inf-IT DAVcl] Blank page,with Internet ExplorerTobias Mueller <muelli@xxxxxxxxxxxxxx>
Re: [Inf-IT DAVcl] Blank page,with Internet ExplorerColin Purcell <colin@xxxxxxxxxxxxxxxxxx>
Re: [Inf-IT DAVcl] Blank page,with Internet ExplorerColin Purcell <colin@xxxxxxxxxxxxxxxxxx>
Re: [Inf-IT DAVcl] Blank page,with Internet ExplorerTobias Mueller <muelli@xxxxxxxxxxxxxx>