What is a good, simple encryption scheme for protecting passwords in a database? I don't necessarily need anything that's hyper-secure nor do I need anything that's lightning fast, but those things would be nice. Primarily, I just want something that's easy to implement without being terribly slow or insecure.
-
Jeff's [You're probably storing passwords incorrectly](http://www.codinghorror.com/blog/archives/000953.html) article is excellent reading on this topic. – Greg Hewgill Aug 27 '08 at 19:23
11 Answers
As mk says, SHA1 or MD5 are the standard ones, along with SHA2.
Update: As processors have gotten faster over the years, hashes have gotten more brute-forceable. It's now recommended you use bcrypt
.
Another update: bcrypt
is still probably good, but if I was writing a new system today I would use scrypt
.
What you want is more generally called a cryptographic hash function. Cryptographic hashes are designed to be one-way (given the resulting hash, you shouldn't be able to derive the original input). Also, the likelihood of two arbitrary strings having the same hash (known as a hash collision) should be low (ideally 1/number of hash values).
Unfortunately, just because your passwords are hashed doesn't free you from having to try really hard to keep the hashed versions safe. Far too many people will use weak passwords that would be vulnerable to an off-line brute-force attack.
Edit - several people have also already pointed out the importance of using a salt. A salt is a constant value that you mix in with the input before using the hash function. Having a unique salt prevents off-line attackers from using pre-computed tables of common passwords (rainbow tables) to brute-force your passwords even faster.

- 26,428
- 5
- 49
- 48
-
2For the OP: When using a one-way hash such as MD5 or SHA1/2, you can't "decrypt" it. That is, you won't be able to recover the original plaintext password from the hash string. To test the password when the user logs in, apply the same hash to the inputted password and compare the two hashes. – Barry Brown Jan 02 '09 at 17:37
If you use MD5 or SHA1 use a salt to avoid rainbow table hacks.
In C# this is easy:
MD5CryptoServiceProvider hasher = new MD5CryptoServiceProvider();
string addSalt = string.Concat( "ummm salty ", password );
byte[] hash = hasher.ComputeHash( Encoding.Unicode.GetBytes( addSalt ) );

- 150,284
- 78
- 298
- 434
Use the SHA one way hashing algorithm along with a unique salt. It is the main algorithm I use for storing my passwords in the database.

- 18,202
- 3
- 54
- 70
The key to better security, I think, is to use dynamic salts. This means that you generate a random string for each new user and use that string to salt the hash. Of course, you need to store this salt in the database to be able to verify the password later (I don't encrypt it in any way).

- 16,713
- 12
- 64
- 77
I second the vote for MD5 or SHA with a salt. Any of the major web development languages have functions built-in for computing the hash (in PHP, for example, the mcrypt package contains the necessary functions).

- 8,906
- 2
- 27
- 30
You need to be using an uni-directional hash algorithm like SHA-1 suggested above with a salt. I would suggest this site for more information. It includes some sample code / implementation. http://www.obviex.com/samples/hash.aspx

- 20,203
- 6
- 33
- 30
For a non-reversible encryption I would most definitely go with SHA256 or SHA1. MD5 has quite a lot of collisions now and a lot of effort has been put into breaking it, so not a good one to use.

- 5,503
- 5
- 35
- 54
If you want to future-proof your solution, I'd recommend SHA256 or SHA512. Cryptographic geekworld is getting the jitters about MD5 and, to a slightly lesser extent, SHA1.
Or, if you can, wait for SHA-3

- 9,567
- 10
- 42
- 62