LWN: Comments on "The case against password hashers"

A very negative article - unduly so for me

anarcat — Fri, 03 Mar 2017 14:02:14 +0000

> 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.

A very negative article - unduly so for me

mathstuf — Fri, 03 Mar 2017 13:11:08 +0000

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

ras — Fri, 03 Mar 2017 02:52:54 +0000

> 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

tialaramex — Fri, 03 Mar 2017 00:07:10 +0000

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

ras — Thu, 02 Mar 2017 23:37:01 +0000

> 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

tialaramex — Thu, 02 Mar 2017 22:21:15 +0000

"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

anarcat — Thu, 02 Mar 2017 15:29:11 +0000

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.

The case against password hashers

anarcat — Thu, 02 Mar 2017 14:59:53 +0000

Folks may be interested in reviewing the notes I had regarding the various password hashers I have reviewed, and that is now public here: https://anarc.at/blog/2017-03-02-hashers-history/

A very negative article - unduly so for me

anarcat — Thu, 02 Mar 2017 14:58:51 +0000

> 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

ras — Thu, 02 Mar 2017 07:17:13 +0000

> 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.

The case against password hashers

anarcat — Sat, 25 Feb 2017 01:37:57 +0000

note that since this article was written (which is 2 days ago), a collision was found in SHA-1. we are therefore at the "Uncork the champagne step. I *believe* MD5 is at the "How adorable" step. Notice also that, in that table, a lot of algorithms didn't make it pass the 12-year mark, but SHA-1 showed an impressive track record at withstanding collisions for a whopping 22 years.

The case against password hashers

Nahor — Fri, 24 Feb 2017 18:45:16 +0000

Password hashers have never really been stateless, the hasher code is a state of sort. You do need to find and install that code, the same way you need to "find" and "install" your password database. Synchronizing/backing up your boorkmarklets is not different from synchronizing/backing up your password database (your bookmarks are stored in a database).

That said, a password manager is still worse since it has to sync/back up two "states": the software *and* the actual database.

The case against password hashers

mjthayer — Fri, 24 Feb 2017 10:20:44 +0000

What about an article on the ups and downs of using a paper-based password manager, including best practices (as far as they are known) if one does?

The case against password hashers

flussence — Thu, 23 Feb 2017 21:08:24 +0000

I used a self-written bash script as a password hasher for a long time. Very portable (it worked anywhere busybox/toybox is available) but not very secure (I skipped the part about multiple rounds... oops).

The flaws presented here are all valid, but what drove me to a proper password manager in the end was having to remember *usernames*!

MD5

jcrawfordor — Thu, 23 Feb 2017 20:37:02 +0000

IMNSHO Low hanging fruit is absolutely the correct focus here, yet these articles have basically sneered at it. Why worry about these less attractive fruit on the low branches, they argue, let us instead assume that everybody on the planet has a jetpack (password vault that's seamlessly and securely backed up somehow yet accessible from all devices) and extensive training, allowing them easily to fly up and pick any fruit we think best. But that's how we got where we are now. That's how we absolutely guarantee we'll be reading the exact same articles making the same arguments in ten years time.

The trick here is that I'm not convinced that password hashers are the low-hanging fruit for most users. There are a lot of features that are really critical to users, perhaps the biggest one being master password recovery, that are very difficult to implement with a password hasher (basically you're requiring the user to keep up a backup regimen on their master password). There is also the issue of two-factor authentication. Knowledge of the master password for a password hasher is equivalent to access to the synchronized vault for a password vault, so the advantage of being able to require two-factor authentication to access the passwords (if not previously downloaded) is lost. I think that this is quite important in practice, since the way most users behave, master passwords will be vulnerable to all of the typical attacks.

Not to mention that there is a bit of an implicit advantage for brute-force attacks on password hashers - if you have a single output password from some kind of leak, you can now locally bruteforce the master password to a password hasher. With a password vault, this isn't true, plus the vault server can enforce attempt limits.

If password managers aren't easy to use, people just won't use them. When it comes to ease of use, I'm just really not convinced that there is any clear advantage to password hashers. They have a lot of sharp edges that offset the advantage of not having to deal with storing/synchronizing a vault.

low-hanging fruit

dkg — Thu, 23 Feb 2017 15:45:32 +0000

IMNSHO Low hanging fruit is absolutely the correct focus here, yet these articles have basically sneered at it. Why worry about these less attractive fruit on the low branches, they argue, let us instead assume that everybody on the planet has a jetpack (password vault that's seamlessly and securely backed up somehow yet accessible from all devices) and extensive training

I completely agree with you that low-hanging fruit is the correct focus, but i don't think these articles have sneered at it at all. They're focused on what the user of these sytsems can do, right now, that should help to protect themselves in the long-term. A password manager is useful protection (damage limitation) against phishing, cleartext password dbs, and browser-based attacks, because without it an attack on one password is pretty easy to cascade into an attack on other accounts -- most people will default to using the same password everywhere, still.

If your claim is that stateless password hashers are better than password managers because they don't need backup or sync or much training and they let users stick with the same password everywhere, how do you deal with changing passwords on systems where that's a requirement? how should password hashers deal with remote system password constraints that don't match the password hasher's default output?

If your concern is that password managers aren't good enough yet that they can be securely backed up and accessible across devices, then these articles point toward low-hanging fruit for software developers -- build a better password manager that addresses these concerns!

Any questions about what responsible server operators should do to protect their users would be a great addition to this series, btw -- there's low-hanging fruit there as well.

The case against password hashers

pwfxq — Thu, 23 Feb 2017 13:16:08 +0000

There's a paper on the weaknesses of Pwdhash:

http://www.flypig.co.uk/papers/dlj-gr-passwords16.pdf

MD5

epa — Thu, 23 Feb 2017 12:05:13 +0000

Doesn't iterating the hash function hundreds of thousands of times get around the "too fast" problem, at least for a decade or two?

MD5

jnareb — Thu, 23 Feb 2017 11:56:14 +0000

The problem with MD5 and other non password-geared hash function is that they are fast, and in case of MD5 can be implemented on massively parallel GPU. You don't need to crack MD5 if you can brute-force guessing of master password.

MD5

tialaramex — Thu, 23 Feb 2017 11:11:30 +0000

"We have seen partial key recovery attacks against MD5 already"

No. There have been partial key recovery attacks against _MD5 MACs_ which are a different application of the algorithm. The attack on MD5 itself was a collision, which is utterly uninteresting for password protection because our problem doesn't involve bad guys picking the password, we're the ones picking the password.

The pwdhash MD5 algorithm vs MD5 MAC might count as an uninteresting distinction, except that the different sphere of application is important to the recovery method proposed. Here's how this works for our password scheme, see if you can spot where it becomes implausible

1. Every day we force the user to try to log in on _a billion different web sites_ controlled by us.
2. Keep this up for about a thousand years
3. Use the MD5 weakness to start guessing password bits using the pattern from our ~ hundreds of thousands of billions of data points collected in this fashion.
4. Why are you still reading this? This was a hopelessly implausible attack, get a real hobby.

The attacks are somewhat plausible against automated systems using MD5 MAC on machine readable data, where incurring so many MD5 MACs might be somewhat practical - they've _probably_ never been attempted for real, but we wouldn't know, so we should take the sensible step of not allowing MD5 MAC. But when you attack individual human login operations it goes from "I suspect that's never actually happened but I agree it's undesirable" to ludicrous nonsense because humans get annoyed after 10 failed logins at one site, let alone thousands, and the proposed attack requires 2^48 to leak bits.

Actual bad guys are mostly just obtaining unencrypted passwords through a mix of knocking off crappy plaintext passwords stored in databases, phishing, and browser-based attacks. _Rarely_ someone will use rainbow tables of MD5 or similar to attack a primitively hashed password database, if it is big enough to be worth the effect involved. In years of my job I haven't seen any bad guys doing anything more sophisticated than that, from their point of view the effort-reward doesn't work. Password hashers existed all that time, and so from where I'm standing it looks like they (at least competently implemented ones) kept people safe all that time.

IMNSHO Low hanging fruit is absolutely the correct focus here, yet these articles have basically sneered at it. Why worry about these less attractive fruit on the low branches, they argue, let us instead assume that everybody on the planet has a jetpack (password vault that's seamlessly and securely backed up somehow yet accessible from all devices) and extensive training, allowing them easily to fly up and pick any fruit we think best. But that's how we got where we are now. That's how we absolutely guarantee we'll be reading the exact same articles making the same arguments in ten years time.