3vilp4wn wrote:I recently got an idea about how to make a hash more secure against bruteforce, and impossible to dictionary attack.
Here's how it works:
1.) Take the password and hash it, so "admin" will become "21232f297a57a5a743894a0e4a801fc3" (I'm using md5 for this example.)
2.) Take the hash ("21232f297a57a5a743894a0e4a801fc3" in this case), and hash it again, so it becomes "c3284d0f94606de1fd2af172aba15bf3".
3.) Store "c3284d0f94606de1fd2af172aba15bf3" in your database. this limits bruteforce attempts to 32 character hex strings, and stops dictionary attacks on the first hash, and takes only twice the CPU.
Can anyone spot any flaws with this?
OOOOO, a fun crypto problem at last! <3
Lets start from the top;
you can have a dedicated server recompute the dictionary, thus you will still be able to perform the dictionary attack. Though that would require the re computation of the entire database and at double the time. But what we can do instead of double hashing the entire dictionary? single hashing the hashes section of available md5 dictionaries. that way we don't need to waste time double hashing it.
Another of my hypothesis;
Collisions become *slightly* more frequent. Let me explain:
Let H(m) be your secure hashing function
Let a, b, c, d, e, f all be passwords that you will be hashing
Let:
H(a) = c
H(b) = c
H(c) = d
we don't care about H(d)
H(e) = f
H(f) = d
Let Alice, Beatrice, Elanor be users, and each use the passwords a, b, e, respectively.
First example; single hashing database;
Alice uses password a, it hashes to c
Beatrice uses password b, it hashes to c
Elanor uses password e, it hashes to f
# collisions = 1
Second example; double hashing database;
Alice uses password a, it hashes to c which hashes to d
Beatrice uses password b, it hashes to c which hashes to d
Elanor uses password e, it hashes to f which hashes to d
# collisions = 2
Thus we have shown a terribly hypothetical scenario where double hashing has caused additional unnecessary collisions. Hence you *can* also say that a birthday attack is more applicable. Though this is purely hypothetical and might not come into play until you have ~1 mil passwords where this might occur some 1 to 10 times. maybe.
So you better goddamn salt those passwords >:(
And finally, lets consider the fact that collision finding attacks have already greatly reduced the time it takes to find a collision for a given hash. Although your method would increase the time it takes to find the collision, it only does so by 2 times. a quick math calculation:
the best attack so far takes 2^21 time to find a collision. to find a collision by brute force, it would technically take 2^128 time because of the 128 bit digest size. you double the time it takes for the best collision finder, as such it would take 2 * 2^21 = 2^22 . By comparing the times 2^128 and 2^22, you barely put a dent in it. For reference sake, 2^21 time is said to take only a few seconds on a regular computer.
As cent said, it's best to simply move on. Go on to SHA-2 or better yet SHA-3, use the larger hash sizes (if you have a choice between 256 bits and 512 bits, use 512), and salt it all.
Reference:
https://en.wikipedia.org/wiki/MD5