6

Why do we encrypt passwords? Is it to protect the password from eavesdropping? to protect the password after saving it in database? both? or for some other reason?

Improve this question

6 Answers 6

Reset to default
10

I wrote a blog article specifically on that subject. Summary: password should be hashed ("encrypted" is not the correct term for that) to protect against attackers who gain read-only access to the database where a server stores whatever it needs to verify passwords.

Improve this answer
7

Encrypting a password is typically used to protect it from eavesdropping. For example, when you log in to a website which has been setup properly, your password is encrypted thanks to SSL. No eavesdropper can snatch the password in transit.

As for saving an encrypted password in a database, unless there is a very good reason to do this and you know what you are doing, this is a bad idea. Storing a digest (e.g., sha-256(salt+password)) is a much better idea. The reason for this is that where is the encryption key stored? On the server. So if a hacker can break into the machine and steal the database, surely she can steal the encryption key and easily decrypt every password.

One valid example I can think of, however, for storing a password encrypted in a database is a password manager.

Improve this answer
3

The right way is not to store passwords (even encrypted), but rather store a salted hash of the password.

Sometimes you do need to store a password, usually to login/access into other systems. Then you should store it encrypted so if somebody gets it (via SQL injection or whatever) he will not be able to use it to access those systems.

Improve this answer
2
  • I think you meant to say "store it hashed" not encrypted.
    – Bradley Kreider
    Nov 16, 2011 at 19:37
  • 2
    @rox0r, that part of AaronS answer refers to credentials for other systems.
    – Hendrik Brummermann
    Dec 3, 2011 at 16:53
3

Use hashing, instead of encrypting passwords. Why? Well, to encrypt something, you need another key (another password). So how would you store that key securely? You would be trapped in a loop.

So, use a hashing function. Looking around the internet, you find millions of articles and suggestions stating to use functions like MD5, SHA1, SHA256, HMAC, Salted Hashes, ... and so on. The list is long, but do not use them.

Use PBKDF2 with a 64-bit salt per user (possibly derived from a cryptographic pseudorandom number generator). One of the reasons for using PBKDF2 over any other hashing function is that it is slow, which means it is not very vulnerable to brute-force attacks. A salt per user helps protect against rainbow table attacks.

So, you would store

USERNAME, PBKDF2DIGEST, SALT

as a record in your SQL table and you are good to go!

(i prefer PBKDF2 over bcrypt since it feels more used and hence more tested)

Improve this answer
2

Hashing is used to protect passwords within the database (Whether in an OS like Linux, or an App). To protect the hash from attacks like rainbow tables, a salt value is add to the hash. The salt will make rainbow tables attacks impractical because the salt value is unique for every user.

Protecting the password from eavesdropping usually uses encryption. For example send the password over SSL.

Improve this answer
2

Please follow Thomas Pornin's answer above. Knowing that you should hash+salt your passwords before storing is not enough. It's just enough information to get you in trouble.

For example, one round of md5 hashing is tremendously weak, with an 8 GPU setup and 33.1 Billion hashes a second, you can break all 8-digit passwords made up with alphanumeric characters in 15 hours.

Thomas talks about bcrypt and PBKDF2 and the background behind using them.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .