Everywhere I have seen people talking about storing passwords in a database, they have almost always used MD5.
What is wrong with AES, or SHA1?
+20
A:
If you store a password encrypted, it can be decrypted. Since many people reuse passwords across many different systems, this is a bad thing. So you use a one-way function, a cryptographic hash function - this way a password can be verified without actually being revealed.
As Greg commented, AES is an encryption/decryption algorithm. MD5 and the SHA family are hash functions, which are the more appropriate ones to use. But steer clear of MD5 nowadays - it's not really seen as secure enough any more. Xiaoyun Wang published an effective collision attack against it in 2005, and its strength is now seen as considerably below its design strength - thus in cryptographic terms it is "broken".
For best results, the standard is to salt and hash a password to store it - google these terms in tandem and you'll find numerous references.
David M
2010-06-29 20:06:55
However, with a salt that makes it ok right?
Metropolis
2010-06-29 20:09:20
As long as it's well salted, md5 is less insecure than a straight md5 hash, and adequate for most sites; though I still use the SHA family or ripemd myself
Mark Baker
2010-06-29 20:09:26
There is a chink in its armour. This doesn't mean that passwords stored salted and hashed with MD5 are vulnerable ... yet. But with the chink in the armour that could lead to further exploits, why take the risk if you have an alternative?
David M
2010-06-29 20:10:22
So if I use SHA.....whats the lowest bit rate I could go and still ensure it is secure?
Metropolis
2010-06-29 20:11:18
Btw. SHA*1* isn't that much better than md5.
svens
2010-06-29 20:11:41
It's also showing chinks, though smaller than MD5, and its design strength was stronger in the first place. One of the SHA2 family is the best bet at the moment.
David M
2010-06-29 20:15:35
Are there any other hash algorithms available other than MD5 and SHA?
Metropolis
2010-06-29 20:24:22
Yes, plenty. MD4 (DO NOT use), RIPEMD, HAVAL etc. But what have you got against SHA?
David M
2010-06-29 20:26:18
Well, I meant "Are there other hash algorithms better, or comparable to MD5 and SHA?" And, like I asked above, whats the lowest bit rate of SHA I could go and still be secure?
Metropolis
2010-06-29 20:32:11
SHA1 is a 128 bit hash, then SHA2 comprises SHA-224, SHA-256, SHA-384 and SHA-512, with those big sizes respectively. You can use SHA-1 quite securely, but it's not seen as a long term secure hash function - any of the SHA2 ones should be fine. Although SHA-224 is a truncated version of SHA-256, there is actually (though it seems mad) research that shows the truncation can actually strengthen the resulting hash. So that's probably the smallest you should sensibly go for IMHO.
David M
2010-06-29 20:35:32
Obviously you have to use one that's available to you though, which SHA-224 may not be...
David M
2010-06-29 20:36:10
Cool, thanks David
Metropolis
2010-06-29 20:36:28
@svens numerous md5 collisions have been generated, to date not a single sha1 collision has been generated. Currently sha1 is still okay'ed by NIST, where as the use of md5() is clearly a vulnerability.
Rook
2010-06-29 20:42:09
@The Rook - succinctly put, +1 - just to prove we're not always at loggerheads... ;)
David M
2010-06-29 20:43:36
SHA512 provides the same security as SHA256, and SHA384 the same as SHA192, btw, just longer hashes.
maxwellb
2010-06-29 21:21:53
In summary: encrypted passwords (AES, Blowfish, etc.) can be easily decrypted. Hashed passwords can't (shouldn't be) easily "de-hashed."
quantumSoup
2010-06-29 21:31:55
+4
A:
MD5 (Message-Digest algorithm 5) is a cryptographic hash function, while Advanced Encryption Standard (AES) is a symmetric-key encryption algorithm, so they are used for different purposes. A hash, like MD5 or SHA is used to verify passwords because it's hard to invert, that is, to obtain the password from the hash-string. An AES encryption, on the other hand, is invertible, the original message can be obtained if you know the key. So, if multiple messages are encrypted with the same key, knowing it exposes all of them, whereas if you manage to find a hash's original string(rainbow tables, etc), you've only discovered the plain text for that particular instance, and you'll have to redo the work to find a sollution for another hash-string.
luvieere
2010-06-29 20:07:31
+1
A:
Because AES encryption is symmetric. Given a password encrypted with AES and the key, you can decrypt the password. This is undesirable, because you almost always want only the owner of the password to know it and don't want to have an easy way to derive the password. The SHA and MD5 algorithms, on the other hand, perform a (mostly) one-way transformation of the password. There is no piece of information (key) that allows you to return the transformed password back to its plaintext form.
Mike Daniels
2010-06-29 20:09:50
The symmetric nature of AES is nothing to do with the ability to decrypt - you can decrypt things encrypted with an asymmetric encryption algorithm as well.
David M
2010-06-29 20:17:57
+1
A:
The use of AES as a symmetric cipher for passwords would be a volation of CWE-257 and there for a vulnerability. It is possible to use a symmetric cipher as a hash function. Old unix passwords use DES as a hash function and newer unix systems use blowfish as a hash function. But even though its a block cipher, its being used as a one-way function, which is a requirement for any password storage system.
For php you should use sha256.
Rook
2010-06-29 20:24:55
CWE-257 sounds strange. "If a system administrator can recover a password directly, (...) the administrator can use the password on other accounts." I mean, how can hashing password help you, when every time you log in you send your password in plaintext to administrator?
el.pescado
2010-06-29 20:33:52
@el.pescado A malicious administrator could modify the application to log the plain text passwords. However, i think this cwe is important because from a hackers prescriptive, the key could be obtained and all passwords could be decrypted in one foul swoop. This makes attacks like sql injection far more serious. There is absolutely no reason to weaken your application by using a block cipher.
Rook
2010-06-29 20:40:08
...unless you want to provide strong authentication protocol, which often requires reversible passwords. Nevertheless, this is often not the case in PHP applications.
el.pescado
2010-06-29 21:06:39
Someone may have access to the password files without being able to alter the code on the system. The use of a one-way hash function for storing passwords minimizes the usefulness of the password file to an attacker.
supercat
2010-06-29 22:17:05
+1
A:
In short: AES is reversable. A hash function is not.
In response to the accepted answer... (sorry, I'm a new user, can't post comments yet...) Salting only prevents Rainbow Table based attacks. It does not protect "weak passwords". To protect the weaker passwords, you will need to use a hash function that has been proven to be slow. A properly configured bcrypt is the easiest way to do this. MD5 and SHA1 are too fast to be secure. (The collisions found with MD5 are unrelated to this problem I'm describing)
All 8-character passwords encrypted with MD5 or SHA1 (even when properly salted) can be cracked by this dude in a single day. Salting does NOT prevent this kind of attack. "Optimizing" the attack to consist of only the ~500k words in the english language... and the 10,000 most common variations of them will crack a huge number of passwords.
BCrypt is stronger against this kind of attack because it (can be configured to be) millions of times slower than MD5. Iteratively using MD5 a million times will theoretically achieve the same thing, but I suggest you stick with well tested libraries instead of rolling your own implementation. BCrypt uses Salting as well of course, and is available in most programming languages. So no reason to NOT use it.
In theory, SCrypt is better, but its too new (and therefore, implementations are probably still a little buggy)
Long story short: http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt
Dragontamer5788
2010-06-29 21:09:16
A:
The main reason why using symmetric (or asymmetric) encryption is not advisable for protecting passwords is: key management. When using encryption, you must protect the encryption key (or the entropies from which the key is derived). And protecting the key is a very difficult task to solve. Hashing (with SHA, MD5, or any other algorithm) solves the problem of key protection, because you don't need to keep any secret value (other than salt, but salt is significantly less sensitive than encryption key; you can store salt in plain text). So if you only keep passwords for authentication purposes (performed by your app), there is absolutely no reason to use encryption; hashing would do just fine. However, there may be cases when you need to be able to decrypt passwords (e.g. you may need to pass users credentials to third party apps). This is the only case, in which the use of encryption would be justified for password storage.
Alek Davis
2010-06-29 21:25:03