There's still the question of why he would need the password hashes. Assuming he wanted the plaintext passwords to see if they are 'complex' and 'strong,' he would have a hard time telling that from the hashes.
5f4dcc3b5aa765d61d8327deb882cf99 and 05b28d17a7b6e7024b6e5d8cc43a8bf7: Which is a dictionary word and which is a string of punctuation? (I didn't salt :))
There's a decent chance the passwords you found aren't the actual passwords either, considering how easy it is to generate collisions for the hash function.
Right; it's a cryptographic hash. Technically there's no such thing as a 'password hash', only password KDFs and their results, which are composed primarily by cryptographic hashes. I think the guy's point was that if you're going to build a password KDF, you might as well use a hash function that's less shitty than MD5 and SHA1.
And if you read that file, you will read that they used DES for hashing. Reminds me of the LM hash. The LM hash generated two hashes using DES from two 7 byte parts of a 14 byte password. Basically they use each individual 7 byte part as a DES key to encrypt a fixed string. Repeat this twice for each 7 byte part, and concatenate the results, and you get the LM hash.
You may be joking, but for the sake of other people who might read that and not know the reality of the situation:
That is not the case. Even just the length makes it pretty clear which hash is in use ( https://en.wikipedia.org/wiki/List_of_hash_functions ), and even assuming some crazy "security" scheme in use for storing them (hashing and then padding, or some such), someone with the hashes only has to figure out one password to figure out the procedure used. Given the high likelihood of there being "password" or "12345" hashed somewhere in there, that's not so hard.
In a real scenarios, use PBKDF2 or bcrypt!
reply