The case against password hashers
In previous articles, we have looked at how to generate passwords and did a review of various password managers. There is, however, a third way of managing passwords other than remembering them or encrypting them in a "vault", which is what I call "password hashing".
A password hasher generates site-specific passwords from a single master password using a cryptographic hash function. It thus allows a user to have a unique and secure password for every site they use while requiring no storage; they need only to remember a single password. You may know these as "deterministic or stateless password managers" but I find the "password manager" phrase to be confusing because a hasher doesn't actually store any passwords. I do not think password hashers represent a good security tradeoff so I generally do not recommend their use, unless you really do not have access to reliable storage that you can access readily.
In this article, I use the word "password" for a random string used to unlock things, but "token" to represent a generated random string that the user doesn't need to remember. The input to a password hasher is a password with some site-specific context and the output from a password hasher is a token.
What is a password hasher?
A password hasher uses the master password and a label (generally the host name) to generate the site-specific password. To change the generated password, the user can modify the label, for example by appending a number. Some password hashers also have different settings to generate tokens of different lengths or compositions (symbols or not, etc.) to accommodate different site-specific password policies.
The whole concept of password hashers relies on the concept of one-way cryptographic hash functions or key derivation functions that take an arbitrary input string (say a password) and generate a unique token, from which it is impossible to guess the original input string. Password hashers are generally written as JavaScript bookmarklets or browser plugins and have been around for over a decade.
The biggest advantage of password hashers is that you only need to remember a single password. You do not need to carry around a password manager vault: there's no "state" (other than site-specific settings, which can be easily guessed). A password hasher named Master Password makes a compelling case against traditional password managers in its documentation:
It goes on to argue that, when you lose your password: "You lose
everything. You lose your own identity.
"
The stateless nature of password hashers also means you do not need to use cloud services to synchronize your passwords, as there is (generally, more on that later) no state to carry around. This means, for example, that the list of accounts that you have access to is only stored in your head, and not in some online database that could be hacked without your knowledge. The downside of this is, of course, that attackers do not actually need to have access to your password hasher to start cracking it: they can try to guess your master key without ever stealing anything from you other than a single token you used to log into some random web site.
Password hashers also necessarily generate unique passwords for every site you use them on. While you can also do this with password managers, it is not an enforced decision. With hashers, you get distinct and strong passwords for every site with no effort.
The problem with password hashers
If hashers are so great, why would you use a password manager? Programs like LessPass and Master Password seem to have strong crypto that is well implemented, so why isn't everyone using those tools?
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. The use of stronger key derivation functions (like
PBKDF2,
scrypt, or
HMAC)
or seeds (like a profile-specific secret) makes those attacks much
harder, especially if the seed is long enough to make brute-force attacks
infeasible. (Unfortunately, in the case of
Password Hasher Plus,
the seed is derived from Math.random() calls, which are
not considered cryptographically secure.)
Basically, as stated by Julian Morrison in this discussion:
You only have one password for all the sites, really, underneath, and it's your secret key. If it's broken, it's now a skeleton-key [...]
Newer implementations like LessPass and Master Password fix this by using reasonable key derivation algorithms (PBKDF2 and scrypt, respectively) that are more resistant to offline cracking attacks, but who knows how long those will hold? To give a concrete example, if you would like to use the new winner of the password hashing competition (Argon2) in your password manager, you can patch the program (or wait for an update) and re-encrypt your database. With a password hasher, it's not so easy: changing the algorithm means logging in to every site you visited and changing the password. As someone who used a password hasher for a few years, I can tell you this is really impractical: you quickly end up with hundreds of passwords. The LessPass developers tried to facilitate this, but they ended up mostly giving up.
Which brings us to the question of state. A lot of those tools claim to work "without a server" or as being "stateless" and while those claims are partly true, hashers are way more usable (and more secure, with profile secrets) when they do keep some sort of state. For example, Password Hasher Plus records, in your browser profile, which site you visited and which settings were used on each site, which makes it easier to comply with weird password policies. But then that state needs to be backed up and synchronized across multiple devices, which led LessPass to offer a service (which you can also self-host) to keep those settings online. At this point, a key benefit of the password hasher approach (not keeping state) just disappears and you might as well use a password manager.
Another issue with password hashers is choosing the right one from the start, because changing software generally means changing the algorithm, and therefore changing passwords everywhere. If there was a well-established program that was be recognized as a solid cryptographic solution by the community, I would feel more confident. But what I have seen is that there are a lot of different implementations each with its own warts and flaws; because changing is so painful, I can't actually use any of those alternatives.
All of the password hashers I have reviewed have severe security versus usability tradeoffs. For example, LessPass has what seems to be a sound cryptographic implementation, but using it requires you to click on the icon, fill in the fields, click generate, and then copy the password into the field, which means at least four or five actions per password. The venerable Password Hasher is much easier to use, but it makes you type the master password directly in the site's password form, so hostile sites can simply use JavaScript to sniff the master password while it is typed. While there are workarounds implemented in Password Hasher Plus (the profile-specific secret), both tools are more or less abandoned now. The Password Hasher homepage, linked from the extension page, is now a 404. Password Hasher Plus hasn't seen a release in over a year and there is no space for collaborating on the software — the homepage is simply the author's Google+ page with no information on the project. I couldn't actually find the source online and had to download the Chrome extension by hand to review the source code. Software abandonment is a serious issue for every project out there, but I would argue that it is especially severe for password hashers.
Furthermore, I have had difficulty using password hashers in unified login environments like Wikipedia's or StackExchange's single-sign-on systems. Because they allow you to log in with the same password on multiple sites, you need to choose (and remember) what label you used when signing in. Did I sign in on stackoverflow.com? Or was it stackexchange.com?
Also, as mentioned in the previous article about password managers, web-based password managers have serious security flaws. Since more than a few password hashers are implemented using bookmarklets, they bring all of those serious vulnerabilities with them, which can range from account name to master password disclosures.
Finally, some of the password hashers use dubious crypto primitives
that were valid and interesting a decade ago, but are really showing
their age now. Stanford's
pwdhash uses MD5, which is
considered
"cryptographically broken and unsuitable for further use
". We have
seen
partial key recovery attacks against MD5 already
and while those do not allow an attacker to recover the full master
password yet (especially not with HMAC-MD5), I would not recommend
anyone use MD5 in anything at this point, especially if changing that
algorithm later is hard.
Some hashers (like Password Hasher and Password Plus) use a
a single round of SHA-1
to derive a token from a password; WPA2
(standardized in 2004) uses 4096 iterations of HMAC-SHA1. A recent
US National Institute of Standards and Technology (NIST) report also
recommends
"at least 10,000 iterations of the hash function
".
Conclusion
Forced to suggest a password hasher, I would probably point to LessPass or Master Password, depending on the platform of the person asking. But, for now, I have determined that the security drawbacks of password hashers are not acceptable and I do not recommend them. It makes my password management recommendation shorter anyway: "remember a few carefully generated passwords and shove everything else in a password manager".
[Many thanks to Daniel Kahn Gillmor for the thorough reviews provided for the password articles.]
| Index entries for this article | |
|---|---|
| Security | Passwords |
| GuestArticles | Beaupré, Antoine |
Posted Feb 23, 2017 11:11 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
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.
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.
Posted Feb 23, 2017 11:56 UTC (Thu)
by jnareb (subscriber, #46500)
[Link] (1 responses)
Posted Feb 23, 2017 12:05 UTC (Thu)
by epa (subscriber, #39769)
[Link]
Posted Feb 23, 2017 15:45 UTC (Thu)
by dkg (subscriber, #55359)
[Link]
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.
Posted Feb 23, 2017 20:37 UTC (Thu)
by jcrawfordor (guest, #114167)
[Link]
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.
Posted Feb 23, 2017 13:16 UTC (Thu)
by pwfxq (subscriber, #84695)
[Link]
Posted Feb 23, 2017 21:08 UTC (Thu)
by flussence (guest, #85566)
[Link]
The flaws presented here are all valid, but what drove me to a proper password manager in the end was having to remember *usernames*!
Posted Feb 24, 2017 10:20 UTC (Fri)
by mjthayer (guest, #39183)
[Link]
Posted Feb 24, 2017 18:45 UTC (Fri)
by Nahor (subscriber, #51583)
[Link]
That said, a password manager is still worse since it has to sync/back up two "states": the software *and* the actual database.
Posted Feb 25, 2017 1:37 UTC (Sat)
by anarcat (subscriber, #66354)
[Link]
Posted Mar 2, 2017 7:17 UTC (Thu)
by ras (subscriber, #33059)
[Link] (8 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.
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.
Posted Mar 2, 2017 14:58 UTC (Thu)
by anarcat (subscriber, #66354)
[Link] (7 responses)
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
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.
Posted Mar 2, 2017 15:29 UTC (Thu)
by anarcat (subscriber, #66354)
[Link] (1 responses)
https://en.wikipedia.org/wiki/Data_Encryption_Standard#Ch...
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.
Posted Mar 2, 2017 22:21 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
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.
Posted Mar 2, 2017 23:37 UTC (Thu)
by ras (subscriber, #33059)
[Link] (4 responses)
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".
Posted Mar 3, 2017 0:07 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
... 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
The researchers just did
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.
Posted Mar 3, 2017 2:52 UTC (Fri)
by ras (subscriber, #33059)
[Link] (1 responses)
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".
Posted Mar 3, 2017 13:11 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Mar 3, 2017 14:02 UTC (Fri)
by anarcat (subscriber, #66354)
[Link]
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.
Posted Mar 2, 2017 14:59 UTC (Thu)
by anarcat (subscriber, #66354)
[Link]
MD5
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.
MD5
MD5
low-hanging fruit
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.
MD5
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 case against password hashers
The case against password hashers
The case against password hashers
The case against password hashers
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
A very negative article - unduly so for me
A very negative article - unduly so for me
* store state to keep track of which passwords were changed
A very negative article - unduly so for me
https://en.wikipedia.org/wiki/EFF_DES_cracker
A very negative article - unduly so for me
A very negative article - unduly so for me
A very negative article - unduly so for me
for x in ('password', 'pass1234','sesame','obama2012') {
p = hash(x)
if p == hashed_password print (p "is actually" x)
}
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)
}
A very negative article - unduly so for me
>
> ... actually does illustrate the thing you'd saying is unlikely.
A very negative article - unduly so for me
A very negative article - unduly so for me
The case against password hashers