Why should I care about hashing passwords anyway?

Question

If a hacker has access to the hashes in my DB, he has access to the rest of the information in the DB anyways. So why would he bother trying to decrypt the passwords? Should

Answer 1

When a hacker access your database it does not mean that he can access the procedural code, those procedures can alter databases outside the hacked database boundaries or inclusive can alter other procedures.

By the way now I´m going to ask you something: If a user is hacked and someone has his or her password, how do you make clear that it is not your application or security fault?

If you don't have stored passwords you don't have such responsability!

Answer 2

If an application is to show grade information at the university then having access to the password will allow you to get the grades for that person. If the password also allows you to log into the online course system then you can submit tests as that user.

If the data is even more sensitive, such as credit card numbers or health records, you are open to lawsuits.

Odds are that the more sensitive information may be on a more secured system, behind stronger firewalls, so they may have found a weakness by hacking into the authentication database.

By hashing the password, then those that have access to the authentication database can't see the password and so log into the very sensitive system as a different user.

Answer 3

Because even if you have access to the data, having access to the APPLICATION is actually more important. The Application makes it much easier to manipulate the data, for example.

Hashing the password prevents casual exposure from all eyes.

For example, you may well have the same password across several sites. A quick glance at the DB not only compromises your application, but perhaps several others.

It's just a good, solid practice to hash you passwords.

Answer 4

Mainly because it's nearly trivial to do it well, and the benefits can be very high.

Answer 5

Best security practices suggest:

• You should use a unique (userId, password) pair for each account you have. But most people use a single pair for many resources (email, bank, etc). An attacker can steal them from one resource and use them to access another. Hashing the passwords with salt—see http://en.wikipedia.org/wiki/Salt_(cryptography)—prevents this sort of attack.

• You should encrypt all sensitive data in your database, not just passwords. Your point that someone might steal your entire DB (or your server) is perfectly valid.

• You should separate your web server from your database and any other precious resources, to quarantine an attack to your least valuable asset.

There are business reasons to hash passwords, as well. Remember, hashing means you do not store your users' passwords anywhere on your equipment.

• Depending on the laws that apply, you may be required to do this in certain situations.

• You greatly reduce your exposure if your data is stolen.

• You're safer from social engineering attacks, in which an attacker impersonates a valid user and cajoles an employee into revealing a password. See http://en.wikipedia.org/wiki/Social_engineering_(security).

Answer 6

Should I be storing the passwords on a different server to the rest of my data?

This adds complexity to your system, but if it's something you can do it's definitely an improvement.

Note that using authentication servers such as Kerberos, RADIUS, or Windows domain authentication effectively put you passwords on another server.