Why should passwords be encrypted if they are being stored in a secure database?

Question

I have a web service. Right now, I have passwords stored in plain text in a MySQL table on my server. I know this isn't the best practice, and that is why I am working on it.

Why should passwords be encrypted if they are being stored in a secure database? I realize that if someone hacks in to my database they will get everyone's password. But I have other problems if someone gets in my database, for example, deleting data.

The scenario I can think of is that you are hacked. You restore a database from a couple of hours ago and everything is well. However, if your passwords are plaintext... The thief has all the passwords and you have to reset them all. Hassle to your users.

If the passwords were encrypted, you could just restore to previous database. Is this correct thinking?

Answer 1

First up, you should be more free with read-only access rights than read-write. It might be possible that a hacker has access to your data but isn't able to edit it.

But, much more importantly, this is not about you. The fact that you might be screwed if someone has full access to your database is irrelevant. Much more important is your user's data.

If you recover your database, the hacker still has access to your user's account.

And who knows what else? What if they use the same password at Google? Or PayPal? What if that gives a hacker access to their mother's maiden name, or the last 4 digits of their credit card?

What if that gets them into other accounts? Don't put it past a hacker to go through a user support system and get more info.

Just ... just don't. That's your user's private information and you don't need to be able to see it. It's also your reputation. Encrypt it.

EDIT: One extra comment, to save any future reader from reading every answer and comment ...

If you're going to encrypt (in the strictest sense) then you need to use a public / private key pair, which is fine but makes life a little bit more difficult for both you and your user.

A simpler, and just as effective, solution is to random-salt and hash the password. Hashing alone is not enough; if your user uses a common password, it will appear in reverse-hashing tables, which are readily available with a simple internet search.

Answer 2

If you get hacked you can restore the site from backups and fix it. But the hacker still has passwords for everyone's accounts! There are documented real world examples of this happening (Sony, Linked-in), where if the password tables had been properly hashed and salted, securing and restoring the sevice quickly would have been much easier.

It's probably a good idea to assume you will be hacked, and design your backup strategy and encrypt any sensitive data with this assumption in mind. And it's not just hackers you need to protect against. Disgruntled, dishonest, or just clueless employees could give away plain-text passwords.

Without hashing you will have to disable access for everyone until they change their password (which, even if possible, will be a huge headache for everyone). If the passwords had been hashed and salted you could restore the web service and it would be much harder for an attacker to gain access to people's accounts.

A properly hashed and salted password is basically one-way. You can't easily guess the password from the hashed password. Even you, as the service provider won't be able to guess it, you can only reset it.

Also, as Elin said, don't try and roll your own hashing (or encryption). Use a standard library.

Answer 3

But I have other problems if someone gets in my database, i.e. deleting data.

It's not about the problems you have, it's about the problems it might cause for all your other users. It's about removing temptation (or even worse, potential liability) for people working on the site to abuse data that's stored there.

See, even though people should use different passwords on different systems, the reality is that don't.

...and since it's so easy to hash passwords, you have no excuses for not following industry best practices.

Answer 4

Noticeable attacks like deleting data are usually the stuff of amateurs, and are the least of your worries. One of the first things an experienced attacker will do is attempt to gain legitimate access, so even if you patch the original vulnerability he used, he will still be able to get in. He will do everything possible to avoid drawing attention to himself until he accomplishes what he desires. By leaving passwords unhashed, you just potentially made his job a lot easier. You also made it harder to detect and isolate his future malicious behavior.

Also, not all compromises give you full shell access. What if the vulnerability an attacker used is just a read-only SQL injection on the users table? Leaving passwords unhashed just gave him pretty much full access.

That's in addition to the reasons given by other answers about your responsibility to safeguard your users' data. My point is, it's not just your users who have something to lose.

Answer 5

I have to post an answer here on a fallacy in the question itself. You are asking if passwords should be encrypted. No one encrypts passwords; no one, with the exception of services and programs like Firefox Sync and Roboform, whose sole purpose is to encrypt passwords.

Let's take a look at the definitions:

In cryptography, encryption is the process of encoding messages (or information) in such a way that only authorized parties can read it.

And hashing:

A hash function is any algorithm that maps data of arbitrary length to data of a fixed length.

In other words, encryption is a two-way conversion and hashing is a one-way conversion, so unless you are decrypting to view them later, this is not encryption.

Also, don't just hash, salt! Read this entire page before you hash your passwords.

As for hashing algorithms, which the OP is now looking into, I would suggest any of the high-end SHA-2 varients, such as SHA-384 or SHA-512.

Optionally, you can use multiple rounds of hashing.

Consider reading this page to secure your login process more.

Second, your database can never be secure enough. There will always be security holes and ever-evolving risks. You should follow Murphy's Law and always prepare for the worst eventuality.

The other points pdr makes are exactly what else I would say: people who use the same password for every website, hackers using social engineering to gain more information, etc. etc.

Answer 6

There is an important principle at stake here. There is only one person who has any business knowing a users password. That's the user. Not their wife/husband, their doctor or even their priest.

It definitely does not include the programmer, database administrator or system technician responsible the the service they are using. That creates a challenge, as the programmer does have a responsibility to receive prove that the user actually knows the password, which is a non trivial problem to solve in a pure way.

The pure solution is to have a mechanism where the user is challenged with some new and unpredictable data, and then has to return a response that is based on this data and their password. One implementation of this would be to ask the user to digitally sign some newly generated data with their digital signature, and we could mathematically prove that they used the same cryptographic key pair that they used to originally create the account.

In practice, the pure solutions require substantial client side infrastructure and processing, and for many websites, this is often not appropriate for the data being protected.

A more common solution would be:

At the point where a password is first received in the application, the password is passed to hashing function, along with you application's random 'salt' value into the hash function.

The original string is then overwritten in memory, and from this point on, the salted hash is stored in the database or compared with the database record.

The key aspects that provide security here are:

1. Knowledge of the hash does not directly provide authentication.
2. Reverse calculation of the password from the hash is impractical.
3. The use of rainbow tables (long lists of passwords and their calculated hashes) is made more challenging because the resulting hash is dependent on both username and password.

Answer 7

You need to "encrypt" (actually, "hash", for a proper notion of hashing) the passwords as a second layer of defence: this is meant to prevent an attacker, who got a read-only glimpse of the database, from escalating that into read-write access and, precisely, begin to alter the data. Read-only partial breaches happen in the real world, e.g. through some SQL injection attack from an account with read-only access, or by retrieving a discarded hard disk or old backup tape from a dumpster. I have written at length on this subject there.

As for the proper ways to hash passwords, see this answer. This involves salts, iterations, and, most of all, not inventing your own algorithms (homemade cryptography is a sure recipe for disaster).

Answer 8

I won't repeat what other people have said, but assuming you have PHP 5.3.8 or better, you should be using the PHP native bcrypt to store your passwords. This is built into PHP. If you have PHP 5.5 you can use the best available password constant. You can also use a library to make 5.3.8 or better behave like 5.5.

Stack Overflow question How do you use bcrypt for hashing passwords in PHP? explains it, and the other replies there explain more. Please don't mess around trying to do this yourself.

Answer 9

I agree with the answer from pdr, for the reasons stated in that answer.

I would add the following: you should do it because it is easy to do and generally accepted as best practice for any application. More specifically, passwords should always be salted and hashed before writing to any persistent storage. Here is a good reference on the importance of salting and choosing a good cryptographic hash (that also provides free source code in several popular languages): https://crackstation.net/hashing-security.htm

The small amount of extra development time is well worth the protection it provides your users, and to your reputation as a developer.

Answer 10

The scenario I can think of is that you are hacked.

Another scenario you need to think of: someone slipped your DBA (or whoever else can run select queries on your DB) $100, to give them the users' passwords. Or social engineers some intern to do that.

Then they use those passwords to log in to user's Gmail... or commerce site... (because people are ... less than smart shall we say - and use the same password across sites).

Then the irate user sues your company for exposing their password.

---

NOBODY (including people in your company) should be able to read plain text password. Ever. There's no legitimate business or technical need for that.

Answer 11

For one, even database administrators should not see the users' passwords. Hashing them will prevent this in case the administrator decides to look at a password and login into their users' account.

Answer 12

Well, it's surprising no one has mentioned this, yet, but what about PHYSICAL security of your database?

You may have the best IT security in the world set up, but that doesn't stop anyone who can gain physical access to your storage media. What happens when your team wins the Superbowl this afternoon, and a small riot erupts in your city's downtown area where your office / hosting provider is? (Given that it's Seattle vs. Denver, two large IT areas in the US, I don't think that's unreasonable). The mob smashes in to your building and while the authorities are overwhelmed, someone grabs some of your hardware with a DB on it that contains clear-text passwords?

What happens when the Feds show up and seize your equipment because some high-level exec was using his position in the company to execute illegal stock trades? Then the Feds use those passwords to investigate your customers, although they did nothing wrong. Then they realize it was YOU that left them vulnerable.

What happens when your IT department forgets to wipe the old RAID drives that held your DB when they do scheduled replacements before "handing out" the old drives to interns, and then their dorm roommates find what was left behind, and figure out they can "sell" it and never have it traced back to them?

What happens when your DB Server blows a motherboard, IT restores an image to your new server, and the "carcass" of the old server gets thrown in the recycling heap? Those drives are still good, and that data is still there.

Any decent architect knows that security isn't something you "bolt on" later with firewalls and operations policies. Security has to be a fundamental part of the design from the very beginning, and that means passwords are one-way hashed, NEVER transmitted with out encryption (even inside your own datacenters), and never recoverable. Anything that can be retrieved can be compromised.

Answer 13

By encrypting, I'm assuming you're referring to password hashing, which is a one way process whose virtue is that it is hard to reverse.

Indeed, there is no value in hashing passwords under these conditions:

• We have some sort of guarantee that the users are not reusing the passwords for multiple sites.

• We have some sort of guarantee that the passwords themselves do not contain personal information (unrelated to their role as security credentials).

These conditions are not met if the users are random individuals from the general public; therefore, the standard practice is to hash passwords.

Regarding the first point, if plain-text passwords leak which are re-used for accounts on other sites, those who obtain the leaked password have instant access to those accounts. Even if a bulletin about the breach is put out which reaches all users, and they all act on it, they will probably not act in time. If the passwords are hashed, it takes time to obtain access; the passwords must be cracked first, and only weak passwords (e.g. dictionary words) will succumb to that more or less instantly. Users with reasonably strong passwords who react to the breach bulletin have a fighting chance to log in to the other sites and change their reused passwords.

Regarding the second point, suppose that, oh, someone living in a country where being homosexual is criminalized uses the password i-am-gay, and a leak of that password gets associated with their e-mail address or other identifying information. Users can put actual personal secrets into passwords, and so we should protect passwords as if they were actual personal secrets.

There is no way to ensure these conditions in practice if the users are coming from the general public, so we encrypt passwords.

Could the conditions be met? If, say, five expert hackers are running a site for themselves, such that they are the only users, then sure, they can store their passwords in plain text. They understand security and know what they are doing. They do not use those passwords, or similar passwords, for any other system, and don't imbue any personal secret into the passwords. Thus the passwords have zero value to an attacker. If the attacker has access to the password, the system is already compromised, and the passwords themselves are not a gateway to anything else.

Answer 14

Why:

1. Because your secure database isn’t secure and hackers can break in and get my password.

2. Because you can read my passwords and you should never, ever be able to read my passwords.

3. Because you can be accused of reading and abusing my passwords.

4. Because if this is ever found out, the xxxx hits the fan.

Answer 15

Furthermore, I would add this:

"Software subsystems" should never authenticate to each other using "passwords." You should be using centrally-managed technologies such as LDAP ("OpenDirectory") and digital certificates. Any database which expects to receive connections only from internal subsystems should – first of all – be firewalled-away from any other requests, but also should be relying on non-password authentication strategies.

Every "internal actor" should be identified, both by its IP address and then by unique cryptographic credentials that only it possesses.

"Passwords" should be accepted only from external users, and they should be authenticated by the external application, not by the database engine.