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 I be storing the passwords on a different server to the rest of my data? That is the only scenario in which I can envision it being useful.

Answer 1

1. Sometimes a hacker doesn't get full access to your DB. Sometimes they find a little SQL injection hole or other weakness that someone didn't code correctly, and so they can only do simple things at first like print out database cells one at a time. If they can print out a real password all of a sudden things get much worse.

2. Things happen: backup tapes are lost, accidentally thrown away, or stolen. A retired system wasn't wiped properly. A breach elsewhere leads to accidental exposure of a database. If a hacker gets access to a snapshot like this he can learn a lot about your system. But if the passwords are still hashed he can't also use the system to do something malicious, like log in as a different user and start changing things.

3. I've heard that most hacks are an inside job. Better to remove the ability even for people you trust to log in as others.

4. It's not about just you. Users tend to share passwords across systems. Maybe some day (God forbid) you have a breach that has nothing to do with passwords, but in the course of that breach your authentication tables will be one of the attacker's targets. If you store passwords in plain-text, you have also just compromised user accounts at many other services, and your very bad day just got quite a lot worse.

If you think this kind of thing doesn't happen, go talk to the guys at reddit.

Answer 2

1. People often use the same username/password for different accounts on other websites (including, e.g., online access to bank accounts).

2. Once you've discovered this hack and have secured your database, the hacker will still have the ability to login to your user's accounts.

Answer 3

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 4

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.

Answer 5

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 6

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

Answer 7

Sometime, you don't know who will be the system administrator. You still want to protect your users from them.. So, by hashing passwords and all important information (such as credit card), you make it really harder for the hacker or administrator. And, I think password should never be written literally. I mean, I used a password since 2 years and I have never seen it written down.. why an administrator that I don't know should see MY password ?!

Answer 8

Using a hashed password prevents the attacker from being able to log into your app even if they know the hash. Your login page asks for the original password, so to log in using it, they'd have to reverse the hash (compute a collision). Using a rainbow table, that's fairly trivial for MD5, for example, which is where salting comes in. Then the attacker needs to know 1) the way you combine the salt and the password (not much security there), 2) the salt (which is likely in the db already) and 3) they have to compute that value for each combination of password and salt. That's a lot more than just computing hashes of common passwords and looking for a match.

Answer 9

The whole LinkedIn "scandal" was all about leaked hashed passwords.

As I see it, security isn't about anything other than making data retrieval inconvenient.

And by inconvenient in the ideal case we mean it'll take you millions of compute years to access (ie single CPU trying to guess at password would take on the scale of millions of years).

If you store passwords in cleartext, that takes a total of 0 compute years to access. The LinkedIn scandal would have looked much worse. All you have to do is SELECT * FROM USERS (either via injection or an insider).

People often reuse passwords, so if people learn your password, it means a whole world of data becomes accessible to them (not just their LinkedIn, for example). So it becomes a very personal risk. As a webmaster it's rude not to at least hash passwords: you don't have that much respect for your users to take the basic step of trying to protect their information.

Even if the hashed password can be cracked, you're at least taking the bare minimum step to protect your users.

Answer 10

If he can decrypt the passwords, he can probably get access to your user's accounts on other sites as well (as, no matter how many times we tell people not to re-use passwords, they do). Storing plaintext passwords is a good way to give away all your users' PayPal, eBay & Amazon accounts.

Answer 11

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 12

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.