This isn't really a practical question, but more a question of curiosity. I heard a CS professor recommend stepping up from md5ing passwords not to SHA1, but to AES encrypting the password using itself as the key. Does anybody have any insight as to whether this is actually more or less secure?
Some thoughts on the matter:
- SHA1 is one-way, which should make it more secure than a function that preserves the data.
- On the other hand, the hacker can't possibly take advantage of AES' decryptable nature because he doesn't yet know the password.
- Unless he guesses it. But then he would be in no matter how I encrypted it.
- Since you know the AES'd password is decrypted when the decryption key matches the output, it could be bruteforced on the hacker's computer.
- But the hacker doesn't know how it's encrypted, so he wouldn't be trying that.
- But the hacker could have got the encryption code as well, in which case it's simply a question of which data takes longer to brute force.
- Most websites use md5 or sha1 (right?), so lookup tables for these hashes would be far more widespread than for the AES method. Thus making the AES method more secure.
- But if we salt both methods, they would become equally immune to lookup tables.
Some common points in the answers, and counter-points:
AES encryption is not designed to be collision resistant, and thus will probably have more collisions for the same hash string length.
If we're using a longer salt, then the encrypted password will be longer than a SHA1 hash. This may be enough to bring the collisions down to a comparable level - or maybe not.
AES encryption tells you how long the password was, within 16 bytes.
We can add to the AES method: after encrypting it, we pad or trim to a reasonable length (which is longer than SHA1's so as to avoid collisions).