Yes, this is 'yet another client-side hashing' question. But, don't leave yet, I think there is some value here.
I'd like to do something to mitigate the affect on the community as a whole when my password hash database is stolen. (See: LinkedIn, Match.com, Yahoo, etc...)
In those cases, statistical analysis of the leaked passwords have been used to improve the heuristics for targeting cracking of a user's password. I'd like to help stop that from happening.
Here is the idea: Take the user's cleartext password, slow-hash it client-side as many rounds as can be stomached. Then, use the hash as the password passed to the server. Treat the password-client-hash just like a normal password and slow-hash again on the server side.
This should make my password database immune to heuristic attacks. (Well, not actually immune, just extra expensive to use the heuristics.)
My concern, though, is that the reduced entropy in the client-side hashing output might eliminate the gains I found in eliminating the value of heuristics.
How can this trade-off be quantified? Any thoughts on the approach?
To be clear, I'm trying to make heuristic attacks less valuable. i.e I want to make 'Password1' as good a password as 'tqwe657fdh'. Meaning, an attacker will have to search the same space to crack either one.
The discussion has helped me clarify my thoughts:
With the recent leaks of so many large password databases, and the resulting analysis of common passwords and patterns, I believe that heuristics used in password cracking systems must have been improved.
Recent advances with GPU assisted hash execution (http://openwall.info/wiki/john/GPU) are further shifting the CPU imbalance benefit back towards the attacker. (Anyway, it was already pretty imbalanced. Its a tall order to handle slow-hashing passwords on centralized server hardware once a system approaches internet-scale.)
I want to do two things:
Eliminate the benefit my attacker receives from the heuristics, thus forcing a true brute-force attack.
Decrease the benefit my password database will have to the cracker community once it is stolen from me.
I suspect my idea might help, but I need a way to quantify the tradeoffs.