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.