Hacker News Reader

Comment by jameshart | Hacker News Reader

One option might be to store a hash of the password with all digits removed alongside the password used. Then once someone uses Seekrit1 as their password, you have the hash of Seekrit too, so if they try to use Seekrit2 later you can tell them not to. Could apply other normalization rules - remove repeated letters; force all lowercase; remove punctuation and digits. That way once someone's used Seekrit1, because you've hashed 'sekrit', they can no longer use seEeEe_kriT23...

View on HN

This is an interesting idea, but my very naive question would be:

Even if the datastore contained only password hashes (which is good), wouldn't it be (potentially multiple) orders of magnitude easier to brute-force password attempts in the event of a large number of potential permutations to be eliminated right off the bat?

Even though bruteforcing the stripped passwords wouldn't provide a full set of information, it might be a good starting point and quickly reduce the search or guessing space.

Disclaimer: I have no idea if this is a practical concern, just one that comes to mind when thinking about your suggestion.

To some extent, you're right. Bruteforcing the password becomes a case of first bruteforcing the kernel by searching the much smaller password space of lowercase letters, then once that's matched using that kernel to generate candidates by altering case, adding digits, etc. Obviously a smart search will immediately try uppercasing the first letter, and adding a 1 to the end, and in a lot of cases that's going to be right. So yes, it does reduce the strength of your encryption against bruteforce password search, by several orders of magnitude.

This is where advances in hashing approaches might negate that problem for you, though - and you'd need a proper cryptographer to figure this out. If it was a plain MD5 or SHA of the normalized password, you're absolutely vulnerable to an attacker using a rainbow table of lowercase alphabet words figuring out the 'root' of the actual password; then they could use that to construct password candidates to hash and compare to the full password. But just adding a big block of salt to the normalized password though would take it out of the pure-lowercase searchspace and force you back to bruteforce searching of the (admittedly small) password space. However, multiround salted hashing strategies like bcrypt rule out rainbow tables and allow you to tune how expensive bruteforcing is, and even though the password space of the password kernel is limited, you may be able to turn bcrypt up high enough to make it unfeasible to bruteforce.... maybe?

I might suggest that the password pattern strings are encrypted using a key based on the user's password plus salt. This way, the password pattern list is only recoverable AFTER recovering the users password (via brute force). I think this solves the reduced search space problem of your scheme.

$a = passwO_rd1; $b = ($a striped down to lower case); $c = ($b's metaphone); $d = md5(md5($a.'salt1'.b).$c.'salt2'); $e = md5(md5($c.'salt3').$c.'salt4'); Store $d as encrypted password then store $e as a string to check against. have $e saved in a separate communal database so to brute force $e and then guess the missing characters and the right user it would be. ([missing characters]^[character set])^([password lengh] ^ [users])^2 or something along those lines

Reply on news.ycombinator.com