views:

815

answers:

10

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.

+44  A: 
  1. Sometimes a hacker doesn't get full access to your DB. Sometimes they find a little SQL injection hole 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. Databases are usually backed up to tape, and sometimes those tapes are lost. 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.

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

Joel Coehoorn
I just love getting 11+ upvotes to one question after I've already maxed out my rep for the day o_0
Joel Coehoorn
+1: inside job. Never store passwords.
S.Lott
+1 just to taunt Joel with more extraneous rep.
Jon B
/> DELETE FROM users WHERE userid="Joel"; <!-- +1, but only if stackoverflow implement's Joel's answer -->
Adam Liss
+29  A: 
  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.

Cybis
+3  A: 

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.

Will Hartung
I disagree. Having access to the live database is a lot more dangerous. At least through the application you're limited to its business rules. The application likely won't allow you to DROP tables, for example, and you can lockout compromised user accounts.
Cybis
+4  A: 

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.

Michael Burr
let's not forget openid ;)
Joel Coehoorn
+2  A: 

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 ?!

Co-location is a good example. It's your server, but it sits in someone else's data center where someone else has physical access to the machine.
Joel Coehoorn
+1  A: 

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.

rmeador
+3  A: 

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

Rich Bradshaw
+6  A: 
Adam Liss
A: 

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!

backslash17
A: 

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.

James Black