Security 108: The Other Stuff

Hashing keeps your users info secure.
Credit: Flickr user FutUndBeidl

We’ve been working on this series for a while now (as you can gather from the series links below), and as such have covered a number of different areas:

• Encyption
• Hashing
• Rainbow Tables
• Salting
• Improper practices
• Key Stretching
• Algorithms

However, there are a couple of things we wanted to mention before we wrap everything up.

Protecting usernames and other sensitive data

So, we now have a securely stored password, but what about the username? Is there any benefit to hashing the username?

On some of our systems, where the username itself is also particularly sensitive, the same process is also carried out for all usernames, with each username having its own salt (independent of the password salt), as well as being combined with a different pepper.

Taking the above factors into account, the end result looks something like this:

Unfortunately, bcrypt isn’t possible for this system, due to limitations on the systems that are integrating with it.

The numbers, Mason, what do they mean?

I made an attempt to work out some numbers here.

If we want a rainbow table of all the passwords from 1 to 7 characters long, including a-z, A-Z, 0-9, we have a total of 2 ^ 41.7028 possible combinations.

That sounds quite spectacularly large, however with new GPU-based password hashing systems, it would be quite feasible for a relatively standard system to develop this rainbow table.

Now, let’s add a 20-character salt. No longer is the hacker working on 1-7 characters long; now it’s 21-27 characters. This works out to a ridiculously large number: 2 ^ 160.7868

Of course, a salt need not only consist of standard characters. What if we had a 20-character salt including the special characters !@#$%^&*()-_+=~`[]{}|:;”‘<>,./?

At this point, the rainbow table approach is getting quite ridiculous. The search space has reached 2 ^ 176.9893 , and it’s now taking decades to complete a rainbow table for a single salted password (remember each salt is unique), even on the fastest mining rig available for the foreseeable future.

So why should anyone go to all this trouble? Simple. You can rest easy knowing that the passwords you store are in safe keeping, and that – even if your database is stolen – your users accounts are safe.

Secure? For now at least.

If there is anything you should take away from this series, let it be these three points:

• Always be vigilant, and remember Moore’s Law.
  Technology is constantly adapting and improving, which means that the toolsets of hackers are constantly improving too. MD5 was once sufficient for password protection (but no longer), as is currently the case for SHA256. If you’re protecting sensitive information, remember to be always monitoring and upgrading your hashing function.

• Think passphrase, not password.
  The length of a password can do a great deal for it’s security. Instead of a single word, try to come up with a series of words familiar to you, like a line from a favourite book. This has the added bonus of being easier to remember. Just make sure that the words are interspersed with characters that aren’t easily predictable: replacing ‘e’ with ‘3’ or ‘o’ with ‘0’ adds very little to the actual randomness of your password/passphrase.

• Cover all sides.
  Don’t forget that a compromised user account isn’t the only attack vector – if your systems are specifically targeted by a hacker, you’re going to face attacks from a huge variety of other angles.  The information we’ve given you here should keep your users safe if your database is stolen, but won’t help if someone gets into your live database.

References:

https://en.bitcoin.it/wiki/Mining_hardware_comparison
http://www.tobtu.com/rtcalc.php
http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html
http://www.cryptopp.com/benchmarks-p4.html

This post forms one part of our Security series. You can find links to the other editions here:

Security 101: What is Encryption?
Security 102: What is Hashing?
Security Interlude: The real-world difference between Hashing and Encryption
Security 103: Rainbow Tables
Security 104: Improper Password Storage
Security 105: Seasonings (or Salts and Peppers)
Security 106: The Importance of Key Stretching
Security 107: The Hashing Algorithm, and why Bcrypt is your best friend
Security 108: The Other Stuff