The Worst Case Scenario: Plain Text

Consider this: A major website has been hacked. Cybercriminals have broken through any basic security measures it takes, maybe taking advantage of a flaw in their architecture. You’re a customer. That site has stored your details. Thankfully, you’ve been assured your password is secure.

Except that site stores your password as plain text.

It was always a ticking bomb. Plain text passwords are just waiting to be plundered. They use no algorithm to make them unreadable. Hackers can read it as simply as you’re reading this sentence.

It’s a scary thought, isn’t it? It doesn’t matter how complex your password is, even if it’s pi to 30 digits: a plain text database is a list of everyone’s passwords, spelled out clearly, including whatever additional numbers and characters you use. Even if hackers don’t crack the site, would you really want admin to be able to see your confidential login details?

You might think this is a very rare problem, but an estimated 30% of eCommerce websites use this method to “secure” your data — in fact, there’s a whole blog dedicated to highlighting these offenders! Until last year, even the NHL stored passwords this way, as did Adobe before a major breach.

An easy way of finding out if a site uses this is if, just after signing up, you receive an email from them listing your login details. Very dodgy. In that case, you might want to change any sites with that same password and contact the company to alert them that their security is worrying.

It doesn’t necessarily mean they do store them as plain text, but it’s a good indicator — and they really shouldn’t be sending that sort of thing in emails anyway. They may argue that they have firewalls et al. to protect against cybercriminals, but remind them that no system is flawless and dangle the prospect of losing customers in front of them.

It should be safe, but it’s only as secure as where the keys are stored. If a website is protecting your key (i.e. password) using their own, a hacker could expose the latter in order to find the former and decrypt it. It would require comparatively little effort from a thief to find your password; that’s why key databases are a massive target.

Basically, if their key is stored on the same server as yours, your password might as well be in plain text. That’s why the aforementioned PlainTextOffenders site also lists services that use reversible encryption.

Unfortunately, it’s not that secure. It’s better than plain text, but it’s still fairly standard for cybercriminals. The key is that a specific password produces a specific hash. There’s a good reason for that: each time you log in with the password IH3artMU0, it automatically passes through that hash function and the website allows you access if that hash and the one in the site’s database match.

Salted hashes are based on the practice of a cryptographic nonce, a random data set generated for each individual password, typically very long and very complex. These additional digits are added to the beginning or end of a password (or email-password combinations) before it passes through the hash function, in order to combat attempts made using rainbow tables.

Websites that take their, and by extension your, security particularly seriously are increasingly turning to slow hashes as an added measure. The best-known hash functions (MD5, SHA-1, and SHA-256) have been around a while, and are widely-used because they’re relatively easy to implement, and apply hashes very fast.

It’s also very adaptive: if a system is under particular strain, it can slow down even further. Coda Hale, Microsoft’s former Principle Software Developer, compares MD5 to perhaps the most notable slow hash function, bcrypt (others include PBKDF-2, and scrypt):

“Instead of cracking a password every 40 seconds [as with MD5], I’d be cracking them every 12 years or so [when a system uses bcrypt]. Your passwords might not need that kind of security and you might need a faster comparison algorithm, but bcrypt allows you to choose your balance of speed and security.”

And because a slow hash can still be implemented in less than a second, users shouldn’t be affected.

Why Does It Matter?

When we use an online service, we enter into a contract of trust. You should be safe in the knowledge that your personal information is being kept secure.

"An easy way of finding out if a site uses this is if, just after signing up, you receive an email from them listing your login details. Very dodgy."
Nope. Some websites use scripts to automatically send your password. No seucirty flaw here.
BUT if after clicking on "I've lost my password", you receive an email with your current then it is stored as plain text.

Rainbow tables are unwieldy beasts. Iterating a hash a large number of times (say 1,234 times) then it would be costly to create rainbow tables for it. If the iteration count is secret, it would be nearly impossible for hackers to figure it out to even make a rainbow table.

Of course, using a salt with a slow hash function is better. Better still is to iterate the number of slow hashes. And not all slow hashes are created equal. They should choose those that cannot be parallelized or has a memory trade-off.

Speaking of storing passwords as plain text - remember those innocent days (say ten years ago) when you forgot your password, all you had to do was click the "forgot" link, enter the email address you registered with, and the site will helpfully email you your password - in plain test? And those were the days when email's were not encrypted - and no one seemed to mind. Oh, those days of internet innocence.

When he’s not watching television, reading books ‘n’ Marvel comics, listening to The Killers, and obsessing over script ideas, Philip Bates pretends to be a freelance writer. He enjoys collecting everything.