The big news in the data security arena this week is, of course, the hack at zappos.com. Thankfully, data encryption software was used to protect credit card numbers at Zappos, so the fallout from the data breach is curtailed to what is generally considered “less sensitive” data (but, as more and more articles point out, the definition of what is deemed “sensitive data” is changing, and now may include what’s traditionally considered “less sensitive” data).
I’m not going to rehash what’s been literally covered by hundreds of news outlets. Instead, I’d like to explore passwords, hashing, and salting a bit. I’ve come to realize that, so far, I’ve been lucky when it comes to proclaiming “call to change passwords” = “no salting.”
Zappos asks customers to change passwords – What is hashing?
Salted passwords elevate security… – Why password salts are necessary
…But are not the end all, be all – Compromising salted passwords
Zappos Asks Customers to Change Passwords
One of the things that Zappos required of its customers is to change their passwords. The company has also asked customers to change passwords at other sites if their Zappos password was reused elsewhere.
Normally, such a request is due to the lack of password salting during the hashing process. If you’re new to the world of password security, hashing is a formula for converting text into some other text. But, it has its particularities:
One-way only. Hashing is designed to make it hard (impossible) to figure out what the original text was. For example, YouAreAUser123 could be converted to $12@f23fW2^1bsASFsd, and there’s no way to convert it back. Because of this, hashing is known as a one-way function or a one-way algorithm. I’ve seen infographics that compare it to making sausage: once you have the end product, it’s impossible to figure out which specific animal it’s constituted from (yes, it’s quite the disturbing analogy. But it sticks with you and illustrates the point very well).
Unpredictable. Although an algorithm is involved, meaning there’s an underlying structured formula, the resulting converted text is quite unpredictable. For example, you can’t figure out what the hashed result of “ha” will be based on the hashed results for “h” and “a”, or “ah”, or “hb”, etc. This also means there will be a world of difference between YouAreAUser123 and YouAreAUser122.
Always the same. On the other hand, a particular hash algorithm will always give the same output given the same input. So, for example, if two users decide to use YouAreAUser123 as their actual passwords, their hashed values would be $12@f23fW2^1bsASFsd, using the example from the first bullet above.
That last point is why the theft of unsalted passwords results in companies strongly suggesting that users change their account passwords everywhere: since the hashing algorithm is not kept secret, and it will always end in the same result, hackers could take a list of words, hash them, and compare their own results with the hashed passwords they’ve stolen.
If they see a match, they can look up the unhashed password in their original list. This is the concept behind rainbow tables, a table of pre-computed hash results.
What about salted passwords, though?
Salted Passwords Elevate Security…
Salting is the process of adding extra characters to the password. Because the presence of one extra character — or changing one character (as in the YouAreAUser123 v. YouAreAUser122 example I’ve given) — results in completely different hashed results, it means hackers will have a harder time figuring out the original non-hashed password.
For example, let’s say that the salt is “a”, added to the beginning of each password. In that case, the user submits his password as YouAreAUser123. The actual password ends up being aYouAreAUser123 and this is hashed for a completely different outcome. The user keeps using his original password, of course. The salting is done by the company’s servers.
When hackers breach this particular password database, they won’t be able to use a pre-configured table to look up the original passwords because the hashes will not match up at all. If salting is used to secure passwords, then, conceivably, users don’t need to change their passwords because of a data breach.
However, this only works as long as the salt is kept secure. If the salt is also exposed, it’s short shrift for a hacker to attach the salt and generate a list of hashed passwords.
Certainly, the hacker will have to wait for the passwords to be generated; however, it’s the computer doing the heavy lifting. After the initial setup, a hacker can just sit back and relax.
…But are Not The End All, Be All
But, there’s still a way to figure out passwords even if the salt is NOT compromised. It hadn’t occurred to me sooner because it’s success has been eliminated to a large degree in the world of encryption software, but salted passwords can be compromised via frequency analysis.
Frequency analysis involves seeing how often something pops up, making an educated guess, testing it, and generally trying to solve a puzzle. For example, with certain early encryption systems, one could guess the underlying message because “e” is the most recurring letter in the English language, followed by “t” and “a,” respectively. So, if “z” shows up the most in an encrypted text, followed by “b” and “a,” then “z = e”, “b = t”, and “a = a”. It’s not always as straight forward as that, but it worked, generally.
The same can be done with hashed passwords because people don’t use secure passwords. Time and time again have we seen people using passwords such as “password1”, “iloveyou”, “trustno1”, and others that regularly show up on hacked password lists.
So, a hacker can compile the frequency of particular hashes showing up; list the top 20 or so; and guess via trial and error as to which hash might correspond to which password (the presence of salt doesn’t matter). In Zappos’s case, it’s implied that 24 million passwords were compromised, so after a little testing, hackers should have figured out the passwords of (possibly) tens of thousands of people.
So, even if Zappos had salted their passwords, it stands to reason it would recommend that customers change their passwords.
One could, of course, use variable salts…but this detracts from the real issue: using strong, secure passwords. If everyone were to use complex passwords, the need for salting would not exist (in theory, at least).
Related Articles and Sites: