Symmetric Salting - remember that salt goes with more than just hash

If you understand hashing and salting then skip the next paragraph.

Stored passwords for logins should be hashed and salted.  Hashing is a one way mechanism to produce a practically unique value based on the given input.  This is useful since we can store the hash (and validate the password whenever needed) without storing the actual password.  The same input will always produce the same hashed value which is useful for validating password logins but it is also problematic since we could determine that Fred's password must be the same as Andrew's password since they have the same hashed value.  This can be taken to an extreme where you roll up the matching hashes across thousands of passwords and can therefore use a common password list to start identifying passwords - think someone looking at your User table with thousands of records looking for hashed passwords with the same value.  The solution is salting which means adding a known random value to each password before hashing it - this makes all the hashed values unique and prevents cross-referencing or dictionary attacks.

If salting is so useful when hashing, shouldn't we use it for symmetric (two way) encryption too?  Think about this the next time you encrypt lots of data in your application ... if someone started looking for identical encrypted values could they deduce things from the data?

A savvy customer using Secret Server noticed this issue a while back.  We were encrypting the data in Secret Server with strong AES 256 bit encryption but we weren't salting the values before the encryption.  This meant that the password "foobar" for one secret would have the same encrypted value when saved on another secret.  Our solution was to use a fixed length of random characters (the salt) which we prepend to each value before encrypting it.  This generates unique encrypted values even if the data being encrypted is the same.  When we decrypt the value later, we simply discard the salt.

A large salt value can also improve the strength of a small value to be encrypted.  Consider the password "x" - it is one character and can be easily guessed.  However if we prepend it with a 32 character GUID then the value to be encrypted is 33 characters long and presents a greater challenge.  (Note: GUIDs may not be the best choice for your salt since they are hexadecimal and have a smaller character set than a pure alphanumeric).

Remember that the strongest encryption algorithms alone won't always protect you from attacks so think carefully about your encrypted or hashed data and the possible ways it could be compromised.

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC.  Our product, Secret Server is a enterprise password manager system for teams to secure their passwords.  Is your team still storing passwords in Excel?