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.
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:
|4||Billyfirstname.lastname@example.org||correct horse battery staple|
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||Sha-1 hash of password|
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||Salt||Sha-1 hash of Password + Salt|
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/)
- 10 Amazing Prizes Under $600 Your Customers Will Want to Win
- How Do I Run a Text to Win Sweepstakes?
- From the MK Promotion Archives: Marden-Kane Advertisements Through The Years
- From the MK Promotion Archives: Hunt’s Great Recipe Hunt
- Why Do People LOVE Cash Prizes