In order to reduce the computational overhead on the server, perhaps one option is to run (at least part of) the hash on the client (eg in Javascript). Does anyone have any idea of how that would perform and if it would be feasible?
Looking at downvotes on the parent post. I am bothered by the fact that participants of similar security discussion so easily downvote or lash out against any questions or ideas that diverge from their favorite mainstream. Seems like a common trend even outside of HN.
It's a perfectly valid post. No one says "use this, this is awesome and secure". If you think the idea is bad, then answer with an explanation. The -1 is simply not useful here. (Neither are one-liners that boil down to -1.)
That's not entirely correct. The scheme that chris_j proposed can help prevent weak passwords from being cracked, since now an attacker needs to do one of two things to crack passwords:
1. Try lots of weak password - hash each one and compare to the list. This is slow, because the hash is slow.
2. Try breaking passwords with the partial hash - in this case the attacker either needs to try very difficult passwords (since these are passwords after a partial hash - what you called the 'real password'), or get the partial hashes from the users, which requires more effort.
Not quite; attackers aren't restricted to using a web interface, so they just send the partial hash directly to the remote site. As far as an MD5 brute force attack is concerned, "very difficult" is exactly as hard as a user-entered password. Keep in mind the purpose of hashing is to mitigate the damage caused by database leaks. Granted, an initial client side hash adds one more step the attacker must take to gain a password that's usable on other sites, but that doesn't protect the original site, unless implemented correctly will be crackable with effectively zero effort, and is unlikely to be implemented correctly.
I might totally be wrong, but for me the consequence of that approach are:
1. The attacker doesn't need the text the user entered anymore, just the precomputed hash
2. Probably the length and alphabet is fixed now, which might obfuscate/protect 'password' or 'test', but reduces the value of a strong password. Granted, this last part is a gut feeling.
Re the gut feeling – this is only a problem if the password has significantly more entropy than the hash. So, worst case MD5 (128 bits), this is potentially bad for people with printable ASCII (97 chars) longer than 19 characters.
But it's still not a real problem since 128 bits of entropy is unguessable in the lifetime of the universe (checking 2^64 hashes a second, which is obscenely many – perhaps every processor on the planet dedicated to the task would be enough – covers 5% of the search space in 34 billion years.)
Thanks for the answer. I can safely say that I'm far from an expert on the subject. If you'd be willing to educate me a tiny bit more though :
Is the first case (judging normal passwords) factoring in that a password varies in length? I mean, stupid thought again: You need to test all one character passwords, all two character password, a hash is fixed in its length?
And I wouldn't want to find the original input, I'd want to get in. For that my totally fallible gut says that I'd need to create a 'word list' of hexadecimal character permutations of length x. Is this really an impossible task?
Sorry, I missed this, but hopefully you will see it.
A hash is fixed, but at a long length. Now, because of geometric growth, the shorter lengths are basically irrelevant (since there are 10s times more 19 character passwords than 18 character ones, 100s or 1000s times more 19 than 17, and so on)
On the second point, yes, exactly, you need a word list of all hexadecimal strings of length x. Again, in the case of MD5 (128 bits), this is all the 32 character hexadecimal strings (since 32 characters * 4 bits per hexadecimal character is 128 bits). Such a list has a length of 2 to the power of 128 by definition - 340282366920938463463374607431768211456 items (about 10^38).
Making a list 10^38 items long is not impossible since that's well below the number of atoms in the earth (about 10^50). It is probably impractical however. Suppose you could store the numbers in iron (the most abundant element), you'd need to store each item of the list in about 0.01 nanograms.
