A very negative article - unduly so for me

Posted Mar 2, 2017 7:17 UTC (Thu) by ras (subscriber, #33059)
Parent article: The case against password hashers

> Password hashing, as a general concept, actually has serious problems: since the hashing outputs are constantly compromised (they are sent in password forms to various possibly hostile sites), it's theoretically possible to derive the master password and then break all the generated tokens in one shot.

But in practice has this actually happened for a hasher that uses something half decent? It seems getting your hands on all those passwords would be difficult to pull off in practice give passwords are supposed to be a secret exposed to no one but the target site.

MD5 is definitely 1/2 decent, but even DES would probably do given most master pass phrases don't have 56 bits of entropy. It's probably worth pointing out that collisions aren't an issue here. In fact the more the merrier - each additional one makes it harder to brute force the pass phrase.

In the mean time, in practice, LastPass and friends have been exploited, multiple times.

I can't comment on the usability issues as I haven't used most of programs the article covered. Most only arise only if you insist the password hasher be stateless. I'm not sure why you would insist on that. There is no reason for a password hasher shouldn't store useful ancillary data under the site name, just like a password manager does. The distinguishing difference it does not store the resulting password, and presumably can still be used to get your passwords back even if you loose the ancillary data.

If you don't insist a hasher is stateless the usability issues should disappear. Both a hasher and a manager have to be told the site you want the password for, both can use the site name as a key for storing and retrieving user name and other data, and both have to somehow move the password from them to the target password field. A password hasher can even rotate password by adding a counter to its state info.

The only real difference is how the password is generated. The manager creates new shiny one using a non repeatable process, and so it must store whatever the non-repeatable bit created. Hasher generates it using a repeatable process, and so nothing has to be stored.

Both approaches have their weaknesses - but it looks to me like the manager has more of them. On the hasher side if someone gets your master password you are gone. On the manager side, they need both the master password and the stored passwords. But those stored passwords must be backed up because losing it means losing everything. Which means there must be copies, in multiple places in the cloud if you are cautious. Those copies have proved to be a vulnerablity, as has their transmission over wires when you use them.

Given the similarities between the two, the negative tone directed at hasher here is a mystery to me.

to post comments

A very negative article - unduly so for me

Posted Mar 2, 2017 14:58 UTC (Thu) by anarcat (subscriber, #66354) [Link] (7 responses)

> But in practice has this actually happened for a hasher that uses something half decent? It seems getting your hands on all those passwords would be difficult to pull off in practice give passwords are supposed to be a secret exposed to no one but the target site.

You do not need to get your hands on all the passwords, but only one, to start the cracking. People often assumes sites are not hostile: this is a serious mistake. Even if sites are not hostile (which you can't guarantee), nothing assures you they will keep sufficient security forever and that your passwords won't eventually be disclosed in one of those massive dumps that happen from time to time. It's always surprising, but lots of sites still store those secrets in cleartext, for various reasons.

> MD5 is definitely 1/2 decent, but even DES would probably do given most master pass phrases don't have 56 bits of entropy. It's probably worth pointing out that collisions aren't an issue here. In fact the more the merrier - each additional one makes it harder to brute force the pass phrase.

MD5 and DES are not "half decent". MD5 is "cryptographically broken and unsuitable for further use". DES has been cracked in a massive distributed attack in 56 hours in 1999 and custom hardware (costing around 10 000$) could break DES in about 6 days *on average* in 2008, on a *single* machine.

And hash collisions don't make it *harder* to recover the plaintext, they make it *easier*, as is demonstrated in the paper refered in RFC6151 that I link to in the article.

> In the mean time, in practice, LastPass and friends have been exploited, multiple times.

Note that I do not recommend LastPass or any other proprietary alternative. The previous article exposes two excellent password managers that, as far as I know, have not been exploited. I would be grateful if you would share exploits against those if you know about any, of course... But I am not aware of serious vulnerabilities in KeePass or Password Store other than the issues mentioned in the article.

> I can't comment on the usability issues as I haven't used most of programs the article covered. Most only arise only if you insist the password hasher be stateless. I'm not sure why you would insist on that. There is no reason for a password hasher shouldn't store useful ancillary data under the site name, just like a password manager does. The distinguishing difference it does not store the resulting password, and presumably can still be used to get your passwords back even if you loose the ancillary data.

Password hashers insist on being stateless, it's not something I just picked out of the blue. It's also one of their main stated advantages over password managers. One reason for *not* storing that information (in the clear, by definition) is that it exposes the list of accounts just like the ".ssh/known_hosts" file used to do. We stopped doing that and we should stop doing so for password managers as well.

> If you don't insist a hasher is stateless the usability issues should disappear.

They should, but they do not, unfortunately. As you rightly point out, browser-based password managers have serious usability-related vulnerabilities that still remain and I think this is clearly explained in the article. This affects more than password hashers, of course, but they are particularly vulnerable because they are more often constructed as browser plugins than password managers.

> Both a hasher and a manager have to be told the site you want the password for, both can use the site name as a key for storing and retrieving user name and other data, and both have to somehow move the password from them to the target password field.

True.

> A password hasher can even rotate password by adding a counter to its state info.

If you have ever actually used a password hasher for a reasonable amount of time, you have either:

* never actually changed a password
* store state to keep track of which passwords were changed

Because it's a major pain point to remember which passwords have been changed and which haven't. It's an incentive to *not* change passwords or keep state.

> The only real difference is how the password is generated. The manager creates new shiny one using a non repeatable process, and so it must store whatever the non-repeatable bit created. Hasher generates it using a repeatable process, and so nothing has to be stored.

It is not the only difference. And there is a severe cost to this approach, as I state in the article...

> Both approaches have their weaknesses - but it looks to me like the manager has more of them. On the hasher side if someone gets your master password you are gone. On the manager side, they need both the master password and the stored passwords. But those stored passwords must be backed up because losing it means losing everything. Which means there must be copies, in multiple places in the cloud if you are cautious. Those copies have proved to be a vulnerablity, as has their transmission over wires when you use them.

... you seem to forget that one major difference between hashers and managers is that you do not need to have access to the manager database to start cracking the master password, which is the case for password hashers. It's not just a matter of "keeping state or not", there's an incredibly risky tradeoff in constantly sending a hashed version of your master secret to every site out there. Just like you do not expose the content of encrypted key material or "/etc/shadow" needlessly, why risk exposing such a dangerous secret like this?

> Given the similarities between the two, the negative tone directed at hasher here is a mystery to me.

I am sorry you perceive the article that way. In the whole password series, I have tried my best to stay balanced and expose facts and my conclusions. I understand that people may reach different conclusions from the same facts, but I am honestly surprised that you would conclude I had deliberate negative intentions in this article. My objectives here are to figure out what is best for everyone. I have maintained a password manager (kedpm) until about 2011 and then I had been using password hashers (since around 2010, actually) until very recently. It is after thorough examination of the crypto primitives and review of many discussions that I reach those conclusions and stopped using password hashers.

Now, of course, if you pose as a fundamental requirement that you cannot *store* any information whatsoever, password hashers not only become interesting again, but mandatory. Yet everyone has to store some information somewhere. I would be very doubtful of users claiming they "don't do backups" or "never store anything": someone does that for them, whether it's "the cloud", your roommate, partner or squirrel friends. It's always "someone else's computer", and usually it's some large private US company running proprietary software. I happen to think it's a good thing to get people thinking about backups, where their private data is stored and the stakes surrounding those issues.

Escaping those by using a password hashers seems like a cop-out to me. But then again, as I say in the conclusion, if you really have to choose a password hasher, I can make suggestions, so hopefully that article will have been useful even for people ready for those compromises.

A very negative article - unduly so for me

Posted Mar 2, 2017 15:29 UTC (Thu) by anarcat (subscriber, #66354) [Link] (1 responses)

Actually, I was incorrect: the EFF cracked DES in 56 hours on a single, custom built machine that cost 250 000$. See:

https://en.wikipedia.org/wiki/Data_Encryption_Standard#Ch...
https://en.wikipedia.org/wiki/EFF_DES_cracker

I would posit that no one is bothering to build those for MD5 because it's now known to be vulnerable and not worth the (economic) effort. But if enough people start using password hashers with weak primitives, it will certainly become interesting again.

And before you think that no one started building dedicated SHA256 cracking machines, just think of the Bitcoin network and what those things could do if they would be repurposed to start cracking password hashes... To put things in perspective, the Bitcoin network is currently pushing out about 10^15 hashes per second, or 4 million trillion hashes per second (TH/s). Compare this with GRC's "Massive Cracking Array Scenario" that assumes a whopping one hundred TH/s. While that kind of computing power will probably not be repurposed to attack *your* password in particular, it certainly puts it in the realm of the possibility these days, especially when you start dealing with state actors or well-funded adversaries.

A very negative article - unduly so for me

Posted Mar 2, 2017 22:21 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

"I would posit that no one is bothering to build those for MD5 because it's now known to be vulnerable and not worth the (economic) effort. But if enough people start using password hashers with weak primitives, it will certainly become interesting again"

No. Nobody is doing that with MD5 because that would be crazy.

The point of the EFF device is that 56 bits isn't an adequate _key size_. Nothing else about DES matters to that device or to the EFF's purpose in making it. A shiny modern cipher with a 56-bit key would get the same response. DES is actually very, very good considering how old it is, just today we think key sizes should be large enough to resist plausible brute force attacks too, and we meanwhile came up with a bunch of features we really want that DES was never designed to accommodate.

The equivalent "key size" for MD5 (which isn't even the same flavour of algorithm) is 128-bits so a brute force search isn't practical. Yes, MD5 is broken, but the _famous_ breaks of MD5 are collision attacks, which don't help you here (except see the first comment I wrote on this article, not relevant to humans). The best published pre-image attack, the sort we care about here, needs 2^123.4 steps and is thus of course unimplementable in the real world. It cemented MD5's status as obsolete, but it has no practical impact.

A very negative article - unduly so for me

Posted Mar 2, 2017 23:37 UTC (Thu) by ras (subscriber, #33059) [Link] (4 responses)

> DES has been cracked in a massive distributed attack in 56 hours

Alright, my DES claim was an overkill. The point I was trying to make is:

- The thing you are trying to protect (the master passphrase itself) probably has less that 56 bits of entropy.

- Unlike a password database, SSL or just about any other crypto application the site that is receiving the password has no idea how it was generated. Thus he doesn't know you are using DES.

So even if this was true:

> You do not need to get your hands on all the passwords, but only one, to start the cracking.

The site is cracking a string generated by an unknown algorithm. Without more information about how it was generated no one is going to try - DES or no DES.

> MD5 is "cryptographically broken and unsuitable for further use"

It's only weakness is it is somewhat prone to collisions. That is irrelevant for this use case.

> they make it *easier*, as is demonstrated in the paper refereed in RFC6151 that I link to in the article

You didn't read the paper RFC6151 linked to, did you? Yes, collisions on the inner hash can reveal the key used. It requires about 2^47 HMAC's. If your source of data is is a stream of packets going by on a gigabit link, that I guess it might be an issue. By when someone needs to enter their password for 2^47 different logins?

> It's also one of their main stated advantages over password managers. One reason for *not* storing that information (in the clear, by definition)

Why on earth does it have to be "in the clear, by definition"? The user enters a master password for managers and hashers. The password can be used to encrypt the ancillary info in both.

> is that it exposes the list of accounts just like the ".ssh/known_hosts" file used to do. We stopped doing that and we should stop doing so for password managers as well.

Agreed, apart from your claim a password hasher must store such information in the clear.

> If you have ever actually used a password hasher for a reasonable amount of time

But I have used a hasher for a long time. In my comment I said "I haven't used most of programs the article covered". The key word was "most", it wasn't "all".

A very negative article - unduly so for me

Posted Mar 3, 2017 0:07 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

The paper gtg linked, http://www.flypig.co.uk/papers/dlj-gr-passwords16.pdf

... actually does illustrate the thing you'd saying is unlikely.

Essentially what they've done is take the optimised pipeline bad guys would use to turn poor quality password hashes into plaintext via a dictionary attack, and add the PwdHash mangling to the pipeline.

So whereas you'd usually be doing
for x in ('password', 'pass1234','sesame','obama2012') {
p = hash(x)
if p == hashed_password print (p "is actually" x)
}

The researchers just did
for x in ('password', 'pass1234','sesame','obama2012') {
p = hash(pwdhash(x,'site.i.stole.passwords.from.com'))
if p == hashed_password print (p "is actually" x)
}

They used 15 million words in their dictionary, and found more than a page of hits (ie Pwdhash master passwords) in the hashes they examined, including Superman1938, a password that is not obviously weak by most people's standards but alas involves a very common cultural reference.

You could argue that people should be using strong passwords with a hasher, after all I use strong passwords, and hopefully you do too. But the researchers point out that Pwdhash is deliberately engineered to pass typical "strength" checks even with trivial input, so it has the effect of encouraging users to cut corners and gives them false peace of mind.

A very negative article - unduly so for me

Posted Mar 3, 2017 2:52 UTC (Fri) by ras (subscriber, #33059) [Link] (1 responses)

> The paper gtg linked, http://www.flypig.co.uk/papers/dlj-gr-passwords16.pdf
>
> ... actually does illustrate the thing you'd saying is unlikely.

Yeah, OK, mea culpa. They targeted leaked password databases that had unsalted (and in one case plain text) passwords (something I see they only mention in the body of the paper), but I guess the argument is you should be safe regardless of what the web site does. It's not an unreasonable argument.

There are two fixes: include the login name in the hash, or use a costly hash (eg pbdkf2, scrypt) to make the pre-generation of the hashes for all common passwords too hard. (Now I see both were mentioned in the referenced paper under "Mitigation".)

That said, if you are using a weak password it's not just the hashes stored on foreign server you log into that are insecure, the database used by the password manager is also equally insecure. If the answer to the latter is "don't use a password manager that might leak your database (such as lastpass)", then the a similar answer for password hashers is "only use one implemented well".

A very negative article - unduly so for me

Posted Mar 3, 2017 13:11 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I talked to a co-worker about this and what he does is have a unique salt for every site. It makes changing passwords simple (change the salt), breaking one doesn't grant any others (without the database), but is currently tied to an extension that isn't allowed on multiprocess Firefox yet. Personally, the browser link kills it for me (I use git annex to sync a KeePass database instead), but it does seem like an improvement over the schemes described here (except for the state sync requirement).

A very negative article - unduly so for me

Posted Mar 3, 2017 14:02 UTC (Fri) by anarcat (subscriber, #66354) [Link]

> The site is cracking a string generated by an unknown algorithm. Without more information about how it was generated no one is going to try - DES or no DES.

This is security by obscurity. With sufficient research, a determined attacker can probably make an educated guess at the password manager you are using, through various means. You do not want to rely on this kind of feature.