We’ll Take Our Password Encryption with Salt, Thank You

Privacy, security and encryption of user data is crucial to Marden-Kane and our clients. Our team of programmers works hard to stay on top of the latest research and trends in data security to ensure the highest standards of privacy and security are met on all data we gather, pass and store on behalf of our clients.

Today’s guest post, from our Senior Programmer Eric Grimm, covers why basic password encryption may not be enough.

 

Use Salt with Your Hash
Use Salt to Prepend or Append a Users Password Before Hashing

In these days of numerous and very public database intrusions, the need to secure your users’ passwords is more important than ever. It’s dangerous, and possibly negligent, to store this valuable information in clear text. Hashing a password is good, but with rainbow tables, it’s trivial for an attacker to find matches.

Briefly, imagine the following situation. An attacker gains access to your database and finds the following ‘Users’ table:

Id Name Email Password
1 Joe joe@example.com secret
2 Jane jane@example.com secret
3 Bob bob42@test.com p@ssW0rd
4 Billy william@example.com correct horse battery staple
5 Miranda mir@test.com p@ssW0rd

 

Now the attacker can log in to your system, impersonating any of those users.

And what if those users have the same password for their banking account? It’s a simple matter to attempt to login to BankingSite.com with any of those emails and passwords, one or more of which will likely be valid.

People tend to use similar passwords, and quite often reuse the same password for multiple sites and applications. So when someone uses ‘p@ssW0rd,’ and you hash it using the sha-1 algorigthm to get a string such as ‘e84e87d73a8d46eaeff81bd460df1d05dd631efd,’ anyone with that same password will have the same hash. Suddenly, multiple hits.

(in this example table, ‘Password’ is not actually stored – just the hash)

Id Name Email Sha-1 hash of password
1 Joe joe@example.com e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4
2 Jane jane@example.com e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4
3 Bob bob42@test.com e84e87d73a8d46eaeff81bd460df1d05dd631efd
4 Billy william@example.com abf7aad6438836dbe526aa231abde2d0eef74d42
5 Miranda mir@test.com e84e87d73a8d46eaeff81bd460df1d05dd631efd

 

This is where salting comes into play. With a salt, you either prepend or append the user’s password with a string of characters prior to hashing. Ideally, the salt should be different for every user.

(in this example table, ‘Password’ is not actually stored – just the salt and hash of the password with the salt)

Id Name Email Salt Sha-1 hash of Password + Salt
1 Joe joe@example.com 53137104 ff0216a2aec750ce58e89594542dad70fee58c7b
2 Jane jane@example.com 1084124015 3ae42f86590c8abc340860823d61b683f382eb21
3 Bob bob42@test.com 1950563466 26ca6da5e157340ab4c2ffd9fad3d52daf7fc293
4 Billy william@example.com 1550478154 eb98daf1d2af1b4349852c1a9ea1115bf98fa669
5 Miranda mir@test.com 1633927877 0f7c9fc3480443d721fbe63c5848eac03b7f9c8d

 

Suddenly, users in your system with the same password have different hashes stored in your database. The attacker will no longer find multiple hits for the same password, and will need to brute force each individual password rather than every password in your system at once. Generally, hackers do not want to spend time on an individual password – they want a lot of results, and they want them now.

This method, while much safer, can lead to some user unfriendliness – and some extra work for the developers – but is certainly worthwhile for your and your users’ peace of mind. No longer can you look up a user’s password when they’ve lost or forgotten it – you can only ensure that the password they enter, when salted and hashed using the same methods, yields the same hash from your database – so a password reset mechanism will need to be put into place.

However, this also tends to simplify your storage mechanisms, as a password and salt of any length will yield a hash of a known character count (40 characters for the sha-1 algorithm). You can then allow the user to enter a password with a length of their choosing (though enforcing minimum character counts or mixed alpha-numeric or cases can still be beneficial). Hackers won’t be able to look at the hash and determine which ones are short passwords that can be more easily brute forced. But when you see a system that tells you your password cannot exceed 16 characters, or that will email you your password in clear text when you’ve forgotten it, you can be sure that they are not using good security practices.

(Credit to XKCD for some passwords – http://xkcd.com/936/)