Security Sense: No, the Passwords Weren't Hashed with Encryption

I see a lot of this sort of this sort of thing:

No, not companies explaining their security defences after they get hacked (actually I see a lot of that too), rather using these terms “hashing” and “encryption” in the same breath when what they really mean is one or the other. I don’t want to pick on Multilplay, they’ve got enough problems to deal with at the moment and besides, they’re in good company.

Last year eBay had a bit of a mishap and naturally concerned customers wanted answers as to how credentials were stored:

Alrighty then. So they’re hashed. No wait – encrypted! Let’s check another source:

“EBay spokeswoman Amanda Miller said the company was making the request ‘out of an abundance of caution’ and that it used ‘sophisticated,’ proprietary hashing and salting technology to protect the passwords.”

Firstly, there are many desirable adjectives to describe cryptographic functions but “proprietary” isn’t one near the top of the list! In fact the first thing any cryptographer will tell you about building your own crypto is “don’t”. But getting back whether the passwords were hashed or encrypted, at least this is an official statement from a spokesperson saying they’re hashed so we’re all good, right? Let’s check how their official statement describes it:

“As a result, a database containing encrypted password and other non-financial data was compromised.”

And… they’re encrypted again. Clearly there is some serious misunderstanding out there so let’s try and clarify things and explain why it matters.

The key difference (pardon the pun) between using a cryptographic hash to store passwords versus encrypting them is the ability to reverse the resulting output of the function. Creating a hash means applying a deterministic, one-way algorithm to an input string which means that what comes out the other end is always the same when the same hashing algorithm is used (the deterministic bit) and that it cannot be un-hashed (the one way bit). Assuming the algorithm itself is not compromised, the only way to resolve the plain text version of a hashed string is to compare it to another hash of the same string which is what happens when you log on. That can still be a problem with hashing and certainly when done badly it may provide little protection at all, but the options are there to create a very robust password storage implementation.

Encryption, on the other hand, involves the use of a key. In the case of resolving an encrypted string back to plain text, if the private key is obtained then that’s exactly what you can do – retrieve the encrypted message. This works great for say, storage of credit cards where you want the data to be protected at rest but need to be able to get it back out again to actually do something useful with it such as charging the card.

It all boils down to this: for user passwords on websites, you should never be in a position to convert the password back to plain text. As soon as the possibility is there for this to happen, you have to start worrying about an attacker doing this. For example, they obtain the private key and let’s face it, when we’re talking about a system being compromised to the extent that they obtain passwords in storage, you have to entertain the possibility that the key was compromised too.

For Multiplay and eBay, all we can do is speculate. They’re probably hashed and you can put the confusion down to a colloquialism and conclude that you simply shouldn’t pay too much attention to security advice via social media accounts! Probably…

Troy Hunt
http://troyhunt.com
@troyhunt
Microsoft MVP - Developer Security