Support: 1-800-961-4454
Sales Chat

Break Out The Shaker – Salting Passwords For Tighter Security


What can safe crackers and hamburgers teach us about preventing password security breaches? And what’s the difference between encryption and hashing anyway? Salting? Bcrypt? We all know that password security is very important; the fear of a password security breach keeps developers up at night, and if it happens at the wrong time it can shatter users’ confidence in your software or stunt your application’s growth. There are a lot of different ways to protect passwords, so how do we know which one to choose?

In this video, I’ll explain the differences between two common password protection methods, encryption and hashing, and I’ll show why they alone are not enough to protect your password database. Hackers have sophisticated ways to crack encryption keys; once they get that key it is like they have a combination to a safe and can loot everything inside. While hashing is a one-way function and offers a level of protection, rainbow tables and pre-computed tables enable hackers the opportunity compromise your application.

So what is an application developer to do? In this video I talk about the importance of first salting a password (or appending a long string of random characters) before hashing. I also provide a recommendation for a slow hashing algorithm to foil hackers with minimal disruption to the user experience of your application.

Be sure to check out Bret’s previous series where he talks about the three things that developers should monitor along with screencasts of how to setup the tools.

About the Author

This is a post written and contributed by Bret McGowen.

Bret McGowen is a software developer at Rackspace, designing and building RackConnect, which lets customers have the best of both traditional and cloud hosting. Bret has spent most of his professional life writing software using Microsoft’s .NET framework but is beginning to see the light and has started to dabble in open source technologies. When he’s not on the jogging trail or volleyball court he enjoys working on and reading about tech startups.

Follow Bret on Twitter at @bretmcg.


Good simple overview of using salts. I’ve been using SHA1 from OpenSSL to hash but I’ll look into bcrypt. Of course, if you leave the salt in plain text in the db, hackers who can compromise db security can easily get it along with the hashed salt & pw, so this security enhancement doesn’t help if the db is compromised but it sure increases password guess work, right? Rainbow tables are fine with single words in the dictionary, but using something like even 3 or 4 Diceware words with the addition of numerics and symbols would make those impractical right? I personally use trigraphs from the dictionary to make pronounceable pws that are not real words and usually 8-12 in length with some numberics and symbols mixed ie. The permutations are too high to allow tables to be used I believe—thoughts?

avatar Daniel Lord on July 6, 2013 | Reply

Obligatory XKCD reference:

It isn’t actually that important to use numbers and special characters – it’s the length of the password that really makes a difference. The length ends up in the exponent, whereas the size of the source character set is the base.

avatar Arunas on August 10, 2013

I’ve thought for a while that the best salt to use on many applications is the user ID. This removes the need to store the salt, provides a unique salt for each user, and is provided by the user each time they log in. Sure, a bad guy can work on cracking a single user whose ID is known, but it pretty much eliminates the ability to use pre-generated tables of hashes and common words.

avatar Ross on July 9, 2013 | Reply

Sure but you might have short userids which make some of them easier to crack. Consider applying a hash (with even a bit of constant salt) to the userid first – and use the result of that as your salt for the password.

avatar Arunas on August 10, 2013

In Windows and using Active Directory (AD), the user’s GUID can be used as the hash. This is a large, unique per user, value

avatar Ouch on August 30, 2013

Tried to post a comment, but your site broke.

avatar Philip Tellis on July 16, 2013 | Reply

Hi Philip,

It seems to be working now. Please try again.


avatar Andrew Hickey [Racker] on July 16, 2013

Hi Andrew, I did try again. Short comments work, long comments (2 paragraphs) don’t.

avatar Philip Tellis on July 16, 2013 | Reply

ok, worked now.

avatar Philip Tellis on July 16, 2013

@Daniel: storing the salt in clear text is not a security issue. The main purpose of the salt is to prevent rainbow table attacks against the entire password database (this assumes the attacker has database access). In order to generate rainbow tables for a large number of users with different salts, you’d need a very large amount of disk space and it really isn’t worth it. It’s only useful in an attack where you target a single user.

Most attackers these days won’t even bother with rainbow tables. Instead they’ll make intelligent guesses about what the password is, and try those. Your best bet is to use a very slow hashing algorithm like bcrypt or pbkdf2 and require long passwords.

avatar Philip Tellis on July 16, 2013 | Reply

To use a rainbow table against a single user requires capturing the hashed password. Since the only place the hashed password is generated or stored in on the application server, this means that the attacker is grabbing data from the application (ouch) or the database (double ouch). If you store a plaintext salt value along with the hashed password, and the attacker has compromised the database where this is stored, then the salt is meaningless since the attacker can compute a new rainbow table. Sure, with bcrypt it will take a while, but it still makes it a time game as opposed to a truly preventative measure. Encrypt the database with a key that the attacker cannot get to and you stand a much greater chance of preventing the effort in the first place.

avatar Joe Tomasone on August 14, 2013 | Reply

None of this matters if you let the government run a big fat pipe into your data centers.

avatar Perry Noya on August 19, 2013 | Reply

Excellent overview.

avatar stephen matlock on August 31, 2013 | Reply

I’ve used mapped characters for Windows administrative PWs as well as the same for salt characters on Windows servers. User accounts are 3 times and out for minimum 2 hours or at work, 3 times and out.

avatar chapcom on September 3, 2013 | Reply


I would highly recommend that you take the extra step of encrypting your SALT before appending it or storing it in a different column. With the latest hacking tools, and the newer hashing systems such as what are being used for BitCoin mining, an incredible amount of hashes per second can be tried, so even with a salt so you have to re-hash everything, it’s highly likely that the password will be resolved in short order.

By first encrypting the salt and even the password, you are adding an extra level of protection. We encrypt both the password and the salt with different keys through different systems before hashing. It adds a little overhead, but the only way to get at the encryption keys is to manage to get into separate internal systems and accessing the services that run there to perform the encryption.

avatar Andrew Taylor on September 4, 2013 | Reply

The code for the most common banking encryption HMAC-SHA1 can be obtainedin the public domain.
this code usually has a key word that you enter to verify your HASH is correct,
your visible output is always 32 characters regardless of the length of the input. But there is a massive problem with what seems to be an extremely complicated hashing algorithm. If “YOU” write the “one way” HMAC-SHA1 code, that same code can be used to crack the 128-bit UGID. I was livid when I had a programmer I hired to write a HMAC-SHA1 code for a well known bank in NYC ask me if I wanted the the small extra code to break the UGID! The 40+ pages of requirements had been delivered by the bank and reinforced by a seminar given by the banks chief security officer. It was kind of amazing that a seed will always generate the same GUID. All that is needed is an average programmer to write the decoding” of the one way hash. I do not know where that SHA1-HMAC documentation was obtained by this bank but they did not seem to have any problems given it away. I have tried using the un-hash program that was written for me . and it is absolutely foolproof when breaking a UGID on a register key or a database password. So,it is a falsehood that a UGID is indeed a one way algorithm or that years of brute force are needed to crack it.

avatar H. Forcelledo on September 22, 2013 | Reply

Let me get this straight; a lesson on password security and cryptographic hashing is being promulgated by the same company responsible for these cryptographic weaknesses?

I’ll go ahead and take a screenshot of this post now in anticipation of it being censored. If it isn’t posted within eight hours, I’ll go ahead and post the screenshot elsewhere.

avatar Philip Paradis on September 30, 2013 | Reply


avatar Yaboo on March 7, 2014 | Reply

Leave a New Comment


Racker Powered
©2014 Rackspace, US Inc.