How necessary is it to Encrypt database password f

问题:

I heard that for security issues it is advised to keep the password field encrypted in the database.

In case of my website only I can access the database. And I have no problem with me viewing others passwords as per our web site policy.

Does this applicable to my website too OR there is some other security reason behind telling this.

回答1:

The guidance is that nobody - not even the user themselves - should be able to see passwords, and that they should not be stored in the database in a way that allows them to be retrieved. This is because there are many ways in which this data can get lost - an administrator may print out a report, and leave it on their desk; an attacker might be able to use SQL injection to run database queries; someone may be able to break into your building and steal a backup tape.

Many customers use the same password on multiple sites - so if your sites is the weakest link, you may be exposing them to risks on other sites if they have re-used their passwords.

The recommendation is to use a cryptographic technique called "hashing", which takes the plaintext password and turns it into a meaningless string; there's no way to reverse the hash, which means that even if I stole the hashed password, I couldn't work out what the original, plain text was.

Hashing the same string twice gives the same hash - so when someone logs in, you hash their plaintext password, and compare it to the hash in the database.

The OWASP link provides further information on this topic, including "salting" the hash.

回答2:

You shouldn't store any passwords in the database at all, encrypted or otherwise.

Instead, store a hash. When user tries to log-in, calculate the hash on the password the user entered and compare it with the hash stored in the database.

Unfortunately, plain hashes are susceptible to so called "rainbow" attacks. If an attacker gets hold of your table, (s)he could just pre-calculate hashes of the whole English¹ dictionary or even of all combinations of characters up to certain length, generating so called "rainbow table", and then rapidly compare it to the database table for hashes that match. Some of your users are bound to use weak passwords that can fail under this kind of attack.

To prevent rainbow attacks, don't hash the password itself. Instead hash password + salt. The salt is a random, user-specific string that doesn't need to be more secret than the hash itself². This introduces variations in hashes, so the attacker can no longer use the same rainbow table for all users. The attacker would in effect have to generate a new rainbow table for each user (and his/her salt), hopefully making it prohibitively expensive.

Lack of salting contributed to the massive security breach of LinkeIn this year. Quote from this New York Times article:

"Salting passwords, security experts say, is Security 101 — a basic step that LinkedIn, eHarmony and Lastfm.com all failed to take."

Of course, that should be just the last layer of a multi-layered defense, the layer designed to make attacker's life harder after they have already read your database. You should try everything in your power to prevent this from happening in the first place, including prevention of SQL injection, strict separation of tiers, proper database security, firewalls, regular patching etc...

---

¹ Or some other human language of interest.

² But should, ideally, be stored separately, behind a well-defined Web service API for example.

回答3:

You mean you think you are the only one that can access it. Security should be implemented in layers so if one fails there's always another behind it.

Passwords should always be hashed and salted.

回答4:

You should always hash passwords. The users have no reason to trust you, and you have no way of knowing whether or not your database has been compromised. With a question like this, I can only assume you have a basic understanding on website security. We live in the days where companies like Sony, the US Govt, Banks, etc are getting their databases hacked weekly. If you think you are exempt to this, then you should post it at the registration as to let your users know that you don't care about their privacy.

There is no reason whatsoever that you should be able to read one of your users passwords.

To implement password hashing, you should take the password during registration and hash it before storing in database. Then when a user logs in, you should hash the password, and then compare the hash to the hash in your database. If they compare, then its the same password.

Also, remember to salt the passwords. This means that if you have a password of "test" and hash it, if a users on another site has the password "test" the two hashes are the same and they can figure out the password based on previous hashes. Salting is like adding extra data to the password prior to hashing, so "test" in your database might actually be "test123" and whenever someone types a password, your PHP automatically appends "123" to it. This way when comparing hashes from your site to another site, the hashes for the same password are not identical.

回答5:

I would like to add one point to the already provided good answers. The hash algorithm should be slow, because otherwise it's easy to brute-force until you find a match. An off-the-shelf GPU can calculate about 8 Giga of combinations, so you can try a whole english dictionary in less than a millisecond!

That's why you should use Bcrypt to hash your passwords, it was designed especially for hashing passwords. It has a cost factor that allows to adapt to future (and therefore faster) hardware.