Why encrypt user passwords? [duplicate]

问题:

Possible Duplicate:
Why aren’t original passwords stored?

Why would one store encrypted user passwords in a database, if the password is the least valuable part of the data? It doesn't seem like it would affect external attacks; setting a limited number of login attempts per day per account would be effective. It doesn't seem like it would affect internal attacks; if someone can access the passwords, they've also got access to the more valuable data in the rest of the database.

Am I missing something here? Shouldn't the entire database be encrypted using user passwords as a key for the password encryption itself to be effective?

Combined his post below with his question:

Ok, I asked the question in a bad way. Let me rephrase this.

If someone breaks into this system, the fact that they have the user's passwords is one of the least of my concerns. I'll be encrypting passwords but in my humble opinion, the other data in the database is way more valuable. Assume that if an internal attacker has that data, they don't care about the passwords.

If nothing else in the database is encrypted and everything else in the database is what an attacker actually wants, did encrypting passwords actually solve anything?

回答1:

Because, hashing passwords will protect it from attacks from inside the organization. This way people who have access to the database won't know the user's password.

People have a habit of using the same password over and over, and so if your database is accidentally compromised, your organization isn't the one that makes the user's other accounts comprised in other organizations. Now should people do this, no, but they do, and it's a lot easier to hash the passwords, than it is to explain to your customers why someone on the inside got a hold of the passwords and caused damage to several accounts in other systems not related to yours.

If you think that this reason is too exaggerated, you might want to know that it actually happened to Jeff Atwood, Stack Overflow creator. He described how the whole Stack Overflow was compromised in his blog post "I Just Logged In As You: How It Happened".

Edit:

To further answer you question, your other sensitive data should be encrypted as well. A lot of cyber attacts are inside jobs, and I hate to say it, but you have to be paranoid about who can see what information. Anything that you deem sensitive that you don't want people to know unless they are specifically authorized to see that data, should be encrypted in the database. You are right there are times when comparing what can be stolen the password isn't that much of a concern to you. The key is "to you". It is to other people, and should be protected along with the other sensitive data in the system.

回答2:

What if you have a SQL injection vulnerability, someone steals your database, and uses the usernames, email addresses, and plaintext passwords you have stored to login directly to your users email accounts, bank accounts, etc. Do you really want to take on that liability? Conversely, do YOU really want to take on the responsibility of being able to see your users passwords in plaintext?

回答3:

Reasons:

1. If someone (from inside or outside) will steal those passwords and publicly release them, you're doomed, you can instantly close your business.
2. Some people use the same password for many services. If some "attacker" can access e-mail address and password, the easiest way is to try if that password also works for that e-mail account.

You don't want this happen.

If you can access someone elses e-mail account, you can request sending forgotten password from victim's various services etc.

回答4:

For internal attacks, if I can remember 5 username/password combos, then go to a public terminal and access those accounts, it's less likely someone will notice the attack than if I used a work machine to directly edit the database or pull out large amounts of data while at work.

And as everyone else pointed out, since we all have a hundred or more places online that all want different passwords... many, many people just use the same password over and over and over again. If the Williams Widget Company loses your name, login, and password, and your bank has the same login and password, and it's tracked back that the Widget Company was who lost your password... there's some muddling of liability there.

回答5:

Because you don't want to fall into the design trap of sending unencrypted passwords, or thinking you can, since you won't have anything unencrypted to compare against, maybe.

回答6:

Ok, I asked the question in a bad way. Let me rephrase this.

If someone breaks into this system, the fact that they have the user's passwords is one of the least of my concerns. I'll be encrypting passwords but in my humble opinion, the other data in the database is way more valuable. Assume that if an internal attacker has that data, they don't care about the passwords.

If nothing else in the database is encrypted and everything else in the database is what an attacker actually wants, did encrypting passwords actually solve anything?

回答7:

Confidentiality, integrity, authenticity, privacy... Remember your first security course, and try to count how many of theses are bypassed with your problem.

Four ? Well, it depends of a more specific view of the issue, but not far anyway :)

回答8:

Also, you don't need to know the user password. Creating the the password hash on the client side is a good idea. Depending on your location there may be legal requirements when storing personal data and passwords.

回答9:

Usually a hash of the password is stored in a database not the raw original text. This is to ensure extra security for the user credentials for external attacks on the system. Comparison of hashes is done to verify the user credentials.

You may want to read more theory on why this is the approach followed inorder to understand it better. Wiki can be a start point for this.

回答10:

When storing the password hash. Don't forget to salt it with something, so reverse lookup of the hash won't reveal the password. Yes, make it a long string before hashing.
I don't understand the last paragraph of the question. Sorry.