What is the point of hashing passwords?

Question

Even when following strict security protocols, and what the user typed is (in this hypothetical situation) completely impossible to derive, the key that the server needs to compare to is still there. And even if that weren't the case, the server admin or someone with that ability could just access the account directly (either with rights to it or by modifying the system itself).

For example, if I ran an email service and correctly stored passwords, it obviously doesn't stop me from getting into their accounts by A. having the system up that way or B. modifying it to let it work that way.

Is the only reason for hashing to protect user's accounts on other sites in the event of a compromise?

Answer 1

Yes. For more analysis, see this blog post: we store hashed passwords because partial, read-only breaches happen (if only through a mislaid backup tape) and we do not want attackers to be able to immediately escalate this breach into full read-write access.

Also, passwords are private data (so many men use the name of their girlfriend as password, and their wife might not be pleased with it), so they should be protected from accidental disclosure to the eyes of sysadmins (or their interns). At least, looking at a database of hashed passwords is safe.

Answer 2

Is the only reason for hashing to protect user's accounts on other sites in the event of a compromise?

No, that's not the only reason. It's also to protect the account on your own site from being accessed by someone who should not have access.

Let's say your site was vulnerable to an SQL injection attack, where you could get the password field of the database for an arbitrary user. Wouldn't you vastly prefer that password field to be a one-way hash? Maybe they can run a time-consuming dictionary attack against the hash, but assuming its key-strengthened (e.g., bcrypt) they shouldn't be able to break it unless its one of the weakest/most common passwords.

Or let's say a sysadmin is fired. Do you want her/him to have had access to all million user names/passwords? Sure, while they were employed they may have had access to see any user's information from their admin account, but now that they are no longer employed they should no longer have any access. With plaintext passwords, they may have memorized or stolen a few passwords which they can use at a later date to break into random accounts. (Furthermore, your system may be required to keep an audit log of who is accessing what information when; so there's a big difference between an admin looking up a user's account information and someone signing in from outside the system looking at their own information with their own password). Granted a sysadmin could store POST parameters from the login page in the webserver logs and get plaintext passwords if they wanted, but it would be suspicious and likely traceable back to them.

Or maybe someone found one of your old database backups. Do you want them to have easy access to all the passwords?

Bottomline is (a) you should hash passwords for security on your own site in a strong way (e.g., bcrypt), and (b) you should never reuse the same password at different sites (as you can never be sure they are taking the proper precautions with it).

Answer 3

Hashing the password protects you in cases where your infrastructure is not as secure as you think.

Despite your best efforts, you will get hacked at some point in your IT career. Your strategy then shifts from prevention (which didn't work in at least this one case) to damage control and disaster recovery. Part of that is ensuring that even if an attacker got hold of sensitive data by dumping the database, he couldn't use it to his further advantage (at least not before you can make enough changes in the system to make that data useless).

Enter the hashed password. Hashing is designed to produce a unique value for a unique message that can still be compared for equality, but that has no apparent mathematical or referential relationship to the original message (and thus cannot be "reverse-engineered" efficiently when given only the hash value). So, your attacker finds a chink in the outer armor, and worms his way into your network. He gets access to the filesystem of your database and pulls your MDF file. He opens it up on his own local computer and looks for user account data that he can use to get even further in. Well, guess what? all he sees is a bunch of gibberish where his ill-gotten passwords should be. The amount of knowledge the attacker gains from seeing the hashes, assuming they were properly salted and employ a cryptographically-secure hash, will provide only the most minimal help to him to get further into your system.

Now, there are easier ways to crack a password hash than to crack other hashed messages, because "through 20 years of effort, we've successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess". However, hashing still has value, especially when you use a hash designed to be expensive to compute, like BCrypt or PBKDF2. When a password hash takes one second to compute, even a weak password (28 bits of entropy) would take up to 8 years to guess by brute force, and if you force users to change their passwords regularly, the attacker has to start over (after attaining the new DB dump) every time.

Answer 4

As the others mentioned, a hashed (non-reversible) password is better because you can look at the database without the disclosure of the users password and slow down an attacker. But there are some other points that are possible when the password is only known by the account owner.

You can encrypt the data with a random key. The random key is then encrypted with the users password. Then only that user can get access, even if someone changes the hash in the database. The downside is of course that if the user forgets the password, all data is lost.

This can even extended with certificates. Everyone can encrypt, but you need the password (which is not reversible from the hash) to read it again.

Such an system would be defeated if you store the clear passwords. Such an system is not usual, but certainly possible. And in such a system, even with full r/w access, you have to intercept the password or the data to get to the data, changing the system, which requires a) a lot of time b) good knowledge of the system and is therefore not as easy.

Edit: Ubuntu uses the user password to de/encrypt the home directory as I described . If the passwords would be stored in clear text, the admin still could access the data. Sure, while the user is logged in or the system is changed to share the keys, copy the home directory etc, the data is not longer safe.

But hashing passwords is like wearing a bullet vest. You could still be shoot in the head.

Answer 5

You cannot think of a compromise as being a simple state of either your compromised or your not. There are different levels of compromise and and different levels of protection to either limit the compromise or alert you to when you have been compromised. While we appear to be seeing an increase in active, targetted 'cybercrime' type compromises, it is important to note that many, some might even suggest a majority, of data compromises have occurred through accident and misconfiguration rather than deliberate 'hacking'. While still limited, the fact your password is hashed provides some protection when that sys admin accidentally changes the permissions on a key file and someone is able to download a copy of the sites password database.

Your point regarding system administrators is valid. This is where reputation becomes very important. If you use an email provider you don't know and have no confidence in, who has no real reputation, then you should be either very concerned or just accept that there is a high chance that a sys admin is reading your email. The point is that in life, we often have to trust people we don't really know that well. We do this all the time. Last time you were at a restaurant, did you trust the waiter with your credit card? How much trust do you place in the receptionist at your medical clinic?

Often we will guage this based on reputation and cost. We know that good security comes at a cost. Unfortunately, what a lot of people fail to recognize is that 'cheap' or budget service providers must cut costs somewhere and all too often, that somewhere is security.

Bottom line is that on most systems, at some level, there will be someone who has complete access to all your information and they don't need your password (there are some situations where this is not strictly true, but they are in the minority, so lets just assume this is not the case). The question then becomes one of whether you trust this service provider with your private data. Are you paying enough to expect a confidential service? Does the provider have a sufficient investment in reputation that they will take sufficient measures to ensure your data is sufficiently protected i.e. adequate vetting of staff, good audit trails and sufficient auditing of processes to ensure business processes are adequate and are followed etc.