Is there any real value in hashing/salting passwords?

Question

I look after a system which holds a lot of "low grade" information, nothing financial but name/address/email etc. Someone has suggested that we up the security from the current in house password encryption algorithm to use ICO recommended hash/salting. I've done a bit of reading around and am struggling to see the benefit, my argument has gone back to the "experts" who are suggesting this but they wont (can't) answer my fairly simple question.

As far as I can tell, hashing/salting prevents the password being read and decrypted by a hacker, and it's excellent for this, no argument. But unless I'm missing something, in order to read the password value the hacker has to have access to the database so they can steal the password values?... if they have access to the database then they don't actually need the password(s) as they can just steal the data direct from the database i.e. the application access they gain from the passwords would give them nothing more than reading the database direct?...

What am I missing?

Answer 1

Users often use the same passwords on multiple sites. Your site might not have any financial data, but what if the same password is used for their bank, or for an online store?

You could argue that this isn't your problem, but it is a common issue, and is why whenever a breach happens, one of the immediate statements is "change your password, and change it on any other sites where you've used the same password".

If your site used something like Bcrypt (without flaws in the implementation - see Ashley Madison), the chances of an attacker being able to work out what passwords have been used is slimmer, and it increases the time for users to be able to change their passwords elsewhere. If you just store the password in your DB without any hashing, an attacker can wander off with the email addresses and passwords and start attacking another site immediately.

Email address and password pairs are often traded between attackers too, in the form of "combo lists", which means that even if the original attacker is only interested in your site, they might be able to get some benefit by selling the data to someone else.

Added in response to comment on question mentioning 2-way encrypted storage

The problem with a 2 way encryption approach is that the information to decrypt must be stored somewhere in the system. If an attacker gains access to your database, there is a good chance they have access to your encryption key too. A hash can't be reversed in this way - online tools for reversing hashes effectively look up the hash in a pre-computed list.

Even if they don't have the encryption key, they might be able to work out what the key was - they can use a known plaintext attack by entering a password to your system and seeing what the result is. It probably wouldn't be a quick process, but it could be worth doing if there were any high value targets in your data (celebrities, politicians...).

On the other hand, with a strong, salted, hash, the only way to find the original password with strong certainty is to hash every possible input, using the appropriate salt. With something like Bcrypt, this would take years, although weak passwords will still be found relatively quickly.

Answer 2

Good question, and I'm glad you asked it. I want people to find this thread when they Google it so they -- hopefully -- won't make the same mistakes that many other companies make.

You shouldn't just hash passwords, you should salt them and make sure your hashing algorithm uses some form of SlowEquals. You shouldn't stop there: you should use a secure hashing algorithm that greatly resists collisions, such as bcrypt or scrypt.

---

Why salt? What are collisions?

I'm going to use md5 as an example because it's very well-known. Do not use it, as it's vulnerable to collisions, and is very fast, which means it's much easier to break. Let's imagine you just hash your passwords without a salt. You would end up producing a static output pretty much every single time.

For example, "myDarnPassword" would end up being converted to "aca6716b8b6e7f0afa47e283053e08d9" when hashed as md5. At this point, you could create a dictionary attack and use rainbow tables. You could even generate a database that converts as many random characters into an easily-searchable database that won't require time-consuming rainbow table lookups. You can slowly create that over time and look up hashes later.

You'd create a table looks like this:

+-------------------+----------------------------------+
| PASSWORD          |           UNSALTED_HASH          |
+-------------------+----------------------------------+
| myDarnPassword    | aca6716b8b6e7f0afa47e283053e08d9 |
+-------------------+----------------------------------+
| pleaseDontSueMe11 | 0dd395d0ec612905bed27020fb29f8d3 |
+-------------------+----------------------------------+

Then you would select from the database somewhat like this:

SELECT [password] FROM [table] WHERE [unsalted_hash] = 'aca6716b8b6e7f0afa47e283053e08d9'

And it would return myDarnPassword, plus any collisions which occurred.

With enough processing power and time, you could create trillions of combinations, and quite easily crack a large number of passwords in a very short time (I might recommend breaking databases up into password lengths because of the sheer number). You'd need a colossal amount of hard drive space for this, though.

At that point, all you really have to do is look it up without wasting processing power on brute-forcing everything every time. And if you've stolen other people's passwords in the past from a database, you can add those, and convert them to hashes. Many websites have already done this.

When a website validates your password, they will compare the password to the stored hash, and if it matches the hash in the database, it's considered a valid password. You may then allow the user to log in.

Salting the hash can help defeat this attack, but it won't save you vs. collisions. You can compare the hacked hashes to your hash list that generated collisions, and then enter that password on a website, even if you have the wrong password: as long as the hash validates, you're pwned.

---

Who cares if someone cracks my passwords? I don't care!

Below is just a small collection of examples of what phishers and other malicious individuals could with your unhashed and unsalted plaintext passwords. It may not necessarily be used to target you directly, but let's say Hacker wants to target Person A. Let's deduce how you can target Person A.

1. You are Hacker. Your job is to hack websites and develop a database to aggregate this information.
2. Person A is a person of interest. Person A shows up in one of your hacked sites database. You now know their email address, and the password they're using for that website.
3. Now you can try to log in to their email address with password you've stolen from that website. Sweet, it works!
4. Now that you have access to their email, you download all of their emails through IMAP, or through their web-mail. At this point, you find lots of interesting things. They're communicating with Person B.
5. You can actually google some people's usernames and email addresses, and it could show websites they post on. This will bring up other websites that the user uses. Maybe you can try to hack those websites, or maybe you can just deduce what they're into. Now you can pretend to be like them, or find additional information. Information/activities could include:
   • Usernames. Person A posts online as Mark Buffalo. That's a relatively unique name. You can then google Mark Buffalo, and look for websites that he posts on. Maybe he reveals more of his personality on other sites?
   • Passwords. Maybe Mark Buffalo has the same password on that website. Maybe you can log in to that website and view his private communications with others?
   • Personal Information. Because you know the identity of Mark Buffalo, what if he shares personal information on certains website? What if he posts on craigslist searching for male or female escorts, and he's left his phone number there? You already found his phone information, so you can find a way to set him up and blackmail him for money/information/power. This doesn't have much to do with salting the passwords unless you don't include the phone number, but they find their phone number on another website thanks to your leak. It's one of the many very powerful ways that information can be collected and used against you. This is, after all, an Information Security forum, so I want to use this example.
   • Family Information. Now it's getting creepy. We've got Mark Buffalo's personal information. Let's look into his social networking. Oh, he has a Facebook account (I don't). Can we access this with the same password? If Buffalo is using the same password/email combination, then probably. And you can probably deduce this from his email that you accessed earlier, where you found a lot of interesting things. We can now log in and read his Facebook messages. Now we know who his family members are. We can then coordinate the blackmail attack more easily.
   • Other Login Information. Since we got access to his email earlier, we see he also has a Skype account. One of them is secret. We log in, and see he's flirting with people on Skype. We now have more blackmail material.
   • Impersonation. You can now log in and impersonate Buffalo on a variety of websites. Maybe he's actually a straight-shooter and never went after any escorts, or anything of the sort? Well, now you can turn him into an escort-seeking reprobate, at least in appearance, by using his credentials to impersonate him online. Imagine the damage that could cause to a politician who was wrongly accused and forced to resign.
   • Things that make it easier to hack other people. You can then send emails to Person B with infected attachments, and pretend you know him. You've read enough emails, so you're able to imitate Mark Buffalo to the point where you seem just like him. You craft the email in a way that leaves Person B unsuspecting of what's really going on, and now you can do the same thing to Person B, or worse.

And that's just a small collection of ideas. There are a lot of different uses for someone else's credentials. Salt and hash your passwords, use collision-resistant hash algorithms such as bcrypt and scrypt, and prevent SQL injection attacks. Please don't turn me into an escort-seeking reprobate! Save Mark Buffalo!

(I'm aware some websites can block your attempt to access their services when using a different IP, but there are many ways around this, and not all websites do this).

By the way, congratulations on your potential class action lawsuit if you get hacked.

Answer 3

A common type of breach is read-only access to the user table. This is because this table is used in the code that does the login for which you don't need to be already authenticated. Gaining the passwords would then allow read-access to all data. But even if the attacker already has full read access on the DB he can still gains write access through the passwords, being able to log in to the account and easily change some data.

Answer 4

One very simple reason for salting and hashing users' passwords is this:

A user's password is his/her secret

No one else should know it. Not you, not your colleague, not the DBA. No one. Simple as that...

Answer 5

Part of salting is to make analysing and stealing the password and use their username/email and password combination on other sites more difficult.

It's fairly common for users to re-use 1 or 2 passwords on multiple sites. Changing your algorithm to one that salts and takes a bit more time (eg. bcrypt, scrypt, and similar) is highly recommended, and fairly simple to implement in most languages.

Answer 6

The purpose of a salt is two fold: first, it introduces a unique(-ish) element to each password, so that if two users happen to use the same password, the hashed text of the password will vary. If User A sees that her password hash is "QWERTYU123", and that User B's password hash is also "QUERTYU123", then User A can deduce that she has the same password as User B.

Secondly, it introduces a significant speed bump to anyone with access to the database who wishes to brute-force the passwords with a dictionary attack. Without a salt the attacker can simply hash "TRUSTNO1" to get the hash "QUERTYU123", then scan the password column to see if that text appears. With a salt, the attacker has to rehash "TRUSTNO1" for each and every row in the database in order to test for a match, adding significantly to the amount of CPU required to check each dictionary entry.

Answer 7

if they have access to the database then they don't actually need the password(s) as they can just steal the data direct from the database

The password is the valuable thing. That is because many, many people re-use the same password. So the password to your pigeon club could be the same one they use for their online banking.

I look after a system which holds a lot of "low grade" information, nothing financial but name/address/email etc.

These are valuable too. I've lost track of the number of emails I have received recently from "eBay" or "Apple" claiming my account has been limited unless I "verify" my details. They are usually obviously fake because they don't mention my real name. But if you store a name and an email address it is much easier to make a realistic-looking mail-out, asking for more personal information. For example:

Dear Mr. Smith of 42 Station Street, Gotham City.

We just realized our club overcharged you this financial year and would like to reimburse you $10. Please reply with your banking details so we can deposit the money to your account.

So, don't dismiss emails and names.

---

The bottom line is, though, that hashing and salting your existing database should only take roughly an hour of coding and testing. Then you can do a "batch convert" of the plain-text passwords to the hashed and salted ones.

Answer 8

Encrypting user information like name, email, etc. and storing in database rather than storing it in a raw format provides an extra level security to your application. Secondly people having access to your database also can't read data easily. Any kind of information that you store which come from any customer has it's secrecy. As it's their data and it's a developers responsibility to store it in a manner that makes it difficult for the hack to make meaning be it low grade info or top secret info. Also,Decrypting and encrypting data should be done at server side as generally servers are kept behind firewall. So it becomes more secure from security perspective.

Answer 9

I can see what you mean if the attacker were able to access the database as well. The thing is though, a well designed security system will only let the database store information that both the user and the server have encrypted individually.

Generally, the password is the first lane of hidden values in which you can have your users give that can be hashed to decrypt their data in order to provide a second layer of security if the database's encryption keys are ever compromised. That way even when there is a breach, the user's data is still safe.

Answer 10

In this context, the point of hashing is based on the idea of a one-way, or trapdoor, function: a function that's easy to compute but hard to reverse. When the user generates a password, the system computes its hash and stores that value in the database. When the user submits a password to get entry to the system, it computes its hash and compares it to the value in the database. If they're the same, great; if not, then the password was wrong, and the user should be prevented from accessing the system. In order to make this work, the hash needs two properties: (1) Different original values hash to different values; (2) It's computationally difficult to go from the hash to the original value.

So, why bother with hashes at all? If someone hacks into your database (not just by computer hacking, but by social engineering attacks, leaving a print-out on the bus, acts of a disgruntled employee, etc.), all they get is a series of hash values. It's hard to recover the original value from a hash value, so this is not very useful to a hacker. If the plaintext passwords are stored in the database, then the hacker wins if the database is compromised; he has direct access to all the accounts and passwords, and he can basically do whatever he wants. This setup also means that you don't have access to people's passwords. This is a good thing; even if you trust yourself, you presumably don't trust--- and shouldn't need to trust--- your counterpart at your bank, your predecessor or successor at work, etc. You shouldn't have to depend on the largesse or whim of an adminstrator in order to ensure that your information is secure.

As for salts, I mentioned above that hashes have to have two nontrivial properties in order to be effective. (There are some additional ones I'm skipping over for now.) Functions having those properties are nontrivial to find, and it would be unwise to rely on the particular administrator of a site to come up with a decent one. Instead, there are widely available hashes that most people use. The point of a salt is to ensure that different sites effectively use different hashes: instead of just hashing 'password', we instead 'salt' + 'password' for various values of 'salt'. This means that if someone uses the same password on two sites, they actually have different hashes on the two systems, so that a hacker can't use one to break the other. Also, without the salt, hackers could just brute force all the hashes for passwords of a reasonable length. I mentioned above that hashes need to be difficult to reverse. If you have a table of all the possible hashes for passwords up to, say, 10 letters (or even just the most commonly-used passwords), then it's trivial to reverse the hash; just look it up in the table.

Answer 11

In addition to the other answers, keep in mind there are many degrees of vulnerabilities between completely secure and full access to a database. A vulnerability might expose only some passwords, or only the first few characters of it, or be difficult to associate with a particular user, etc. Hashing and salting can keep a minor breach from turning into a major one.

Also, intruders like to limit their own exposure. The longer they use a vulnerability or back door to get into a system, the more likely they are to get discovered and locked out before accomplishing their objective. If you leave your passwords unhashed and unsalted, you've just given them a very easy way to get back into the system posing as any user, that is extremely difficult to detect and mitigate.

Answer 12

I think the best way of putting this is: the year is 2015, the most private and personal information your users are entrusting to you is their password and user id. Protect it, not with your life but with your ignorance, not with your ability, but your inability.

If you do not know their password and have no way of recovering their password, then no one can steal it from you or force you to divulge it.

Any competent digital thief, given a choice between a thosuand names and addresses and a thousand email addresses/usernames and passwords, will take the later every time.

I understand about cost and time, but if done correctly, from the start, it really doesn't take any extra time at all, and switching to a more secure method isn't that time consuming.