Traditionally, when we salt something, it’s for the purpose of eating it. And, generally, salt is accompanied by pepper. But here we’ll be going against both of these sacred traditions as we deal with salts that are related to password security.

In a nutshell, a salt is a set number of pseudo-random values that are concatenated with a password before said password is hashed and stored (see below). The values and length of a salt have no bounds, both factors merely need to be enough to satisfy the current situation’s need set.

Consider the traditional, barebones protocol for authenticating users when they attempt to login. First, the user must create a password when they first register.

1. User creates password for the first time.
2. User submits password.
3. System accepts password.
4. System hashes password.
5. System stores the hash in the database with a link to the user’s name.

To authenticate the user when they attempt to log in later, the process is very similar.

1. User remembers their original password.
2. User submits password.
3. System accepts password.
4. System hashes password.
5. System compares the hash against the one already in the database.

To use a salt in this process, just add one more step between steps 3 and 4:

3. System accepts password.
4. System salts password.
5. System hashes password.

The concept is very simple. Before hashing the user’s password, it is salted (which means that the salt is added to the password). This results in a final password that is just the user’s password combined with a simple set of randomly chosen values.

The process of actually salting the password is simple. First, a bunch of random characters must be obtained. Likely, for most practical purposes, the salt will be a pre-calculated string of characters stored in a database somewhere. These characters are then added to the password — they can be added to the front, back, middle, front and back, anywhere.

For example, if the original user-entered password was “brad” and the salt to be used was “qpalzm” and the salt was to be added at the beginning of the password, the resulting password, after having been salted, would be “qpalzmbrad”. (Thus, technically, salts don’t just consist of a set of random values, but also of a location to place them.)

When we add salt to food, we do so to add some “kick” to the food’s flavor so it isn’t so bland. We add some spice to make a food that is (potentially) undesireable more desireable. When using salts in password security, it’s basically the same concept: we’re adding random values (the salt) to the user’s password (the food) make the password, as a whole, more random (flavorful). We’re adding some spice to make a password that is (potentially) undesireable more desireable. When a user creates a password to use for their login identity on a system, the system’s administrator is not guarantied that the user’s password is secure, it may consist of very common letter and/or word combinations and thus be easily broken by a dictionary brute-force attack. To prevent this sort of an attack, the admin can use a salt (consisting of random values) on the user’s password to spice it up, making it no longer vulnerable to a dictionary attack and also more impervious to a linear BF attack. (Granted that it is not the administrator’s job to ensure that the user’s password is secure, but it can never hurt to help out a little. Also, adding a salt can allow for the password’s character range to be expanded to include character values the user themselves could not enter.)

Before you can understand what security a salt offers, you must first understand the two types of attacks that exist to break hashes.

The first attack is the simple brute-forcing method. This is where the attacker guesses many possible combinations of hash input values in an effort to find an input that yields the same hash output. The attacker can simply brute-force linearly (by trying literally every combination of characters) or he can use a dictionary of words and character patterns that are more likely to occur in the password, thus potentially shortening his job. Either way, the attacker is just going through a long, long list of inputs hoping to find one that yields matching output.

A more effective attack uses pre-compiled hash dictionaries. This is where the attacker takes a list of input values and compiles the hashes for all of them. Then, whenever he needs to break a hash, the attacker simply finds the hash in his database and looks up the corresponding input text that created it. This method is faster than simply brute-forcing the input text for the hash because the hashes don’t need to be computed for every combination tried because they already exist. (Usually, these pre-compiled hash dictionaries are called “rainbow tables”.)

Salts help against these two attacks, but exactly what they offer depends very much on whether or not they are made public or kept private.

Salts are considered public when no effort is made to conceal the salt’s value — in fact, effort may be made to make it as easily accessible as possible. If a file is being encrypted, the salt may be stored as header data in the encrypted file, if the salt is being used for an online service, it may be stored in a cookie on the user’s computer. It doesn’t matter where it’s stored, really, because it doesn’t matter who knows it and it will probably change a lot.

Advantages of public salts: A good salt will be long and have no common pattern, and thus, when combined with the user’s password, will produce a final password outside the bounds of any (reasonably sized) hash dictionary. Hash dictionaries can only contains hashes for so many input values, and so if the salt is long enough, it will cause the final password to fall outside the dictionaries bounds. Also, by making the salt public and stored someplace where the user takes care of it, the salt can be unique for every user, thus ensuring that no salt is used twice. This means that it would be pointless for an attacker to recompile their hash dictionary taking into account the salt, because the salt will only be used once. Also, because the salt can be changed at will, even if it were kept static for everyone it could be changed for sheer convenience, if needed.

Disadvantages of public salts: Because the salt is public, the attacker would know it’s value and could re-compile his hash dictionary, only this time using the salts on all the generated values to hash. This would only be an efficient time trade-off if the salt were used for a large number of passwords that needed to be broken, so if the salt is only used once (as stated above) this is useless. Public salts do nothing to hinder brute-force attacks, however, because a brute-forcer could simply add the salt to all of his brute-force input attempts.

Salts are considered private when measures are taken to prevent those without a certain authority level from learning the value of the salt. In such a case, the salt would probably be stored somewhere in a file or database with restricted access permissions. It would never be stored or displayed anywhere it might be obtainable by non-cleared users.

Advantages of private salts: Private salts have the advantage of preventing hash dictionary attacks just like public salts (preventing dictionary attacks is the prime reason salts are used in the first place). They also have the benefit annoying the hell out of brute-force attackers because salts make the password longer than they would be otherwise, and if the salt is private then that means the size of the input that the attacker has to guess is longer. If the attacker is trying to brute-force the password but has no idea what the salt is, then every bit of the password, both the user-entered and the salt portions, are unknown. If the user’s original password was two characters long and the salt is 12 characters, then the final password is 14 characters long. A brute-forcer would be able to brute-force a two character password, but 14 characters is outside reasonable limits. Thus, as long as the salt remains unknown to the attacker, the length of the salt added to the length of the password is the total length that the attacker must brute-force.

Disadvantages of private salts: The hardest part of dealing with private salts is that they must actually be kept private, which can prove difficult. This is impossible to do in stand-alone encryption programs (and such) where the user has the actual program that does the salting process on their computer because the program can be reverse-engineered, revealing the salt. In such a case where the salt is discovered, it is no better than a public salt, except now the administrators have a false sense of security regarding their salt. However, in online systems, like bulletin boards, keeping the salt secret can be easier, since only the administrative staff (we hope) has access to the board’s code and database where the salt is stored. However, if the board itself is open-source, or easily obtainable by anyone with access to such a board’s code, then an attacker could just download their own copy of the board (even from a friend) and look through the source code for the salt. To prevent this, the salt would have to configured so that it was generated randomly for every individual board upon installation, so that someone would need access to that specific board to determine its salt. Aside from the difficulty of actually keeping private salts private, the only other difficulty associated with private salts is in keeping them consistent. You can’t just change the standard salt on a whim if you want, so it must be constant across time. Also, storing a private, separate salt for every user in a system might prove obnoxious, so not only must the salt be consistent across time, but it will most likely need be consistent across all users.

Now, the actual security a salt offers, regardless of whether it is private or public, is (obviously) the actual value of the salt. As it is with the password’s they protect, a salt should not be something easily discovered.

First, the length of the salt is critical, choosing a decent length can ensure that both it and the resulting password are beyond any reasonable brute-force attempts that could be made. And, as mentioned before, forcing the length of the final salted password to be pretty long should exclude it from most rainbow tables that will be generated.

Second, the character set for the salt has the potential to be of great help. In almost all password situations, the user only has the ability to choose a password consisting of ASCII keyboard characters, giving an absolute maximum range (if upper-case, lower-case, numeric, and special are all taken into account) of about 96 values. The salt, however, is not entered by keyboard and thus can take full advantage of all 256 values a byte offers. By making the salt itself use a character range outside the traditional ASCII keyboard range, it ensures that at least 99% of all brute-force attacks, against situations that use private salts, are doomed to fail because the attacker fails to account for anything outside the ASCII character range. Even if the attacker knows the character set of the salt (but not the value of it), if the salt uses the full 256 value range, it makes brute-forcing literally millions of times harder, and a brute-forcing task that would have been feasible with an ASCII character range can be made beyond impossible. Most brute-forcing applications do not even support using characters outside of ASCII, thus the attacker may not even have a feasible way of attacking the password or salt to begin with. Using non-ASCII keyboard characters in a salt (whether it’s public or private) is a dirty trick, but all’s fair in computer security.

Obviously, when a salt is private, serious attackers will want to determine it. Is this possible?

The answer is both “yes” and “no”. “Yes”, as in it is possible to find where the salt is stored and directly read it. “No”, as in it is safe to say that no one will never understand mathematics well enough to extrapolate regions of consistent input to hashes (meaning that separating the salt from the password, given only a finally hash, is mathematically infeasible).

The only feasible way to discover a salt is to find out where it is stored and read it. This can be done by hacking a database, downloading a copy of the software and examining it for yourself, or social engineering. Regardless of how it’s done, reading the salt from where ever it is stored is by far the attackers best option.

Aside from compromising the salt’s storage location, there isn’t much that can be done to discover a private salt’s value. Reversing a hash is completely out of the question so don’t even entertain the idea for a millisecond — hash collisions have been produced, but no one has ever reversed a (well-designed) hash. The only plausible way to discover a salt’s value would be to obtain the final hash of a user’s password where the password is known (basically, if you could get the final hash for your own password that would be great). Then, knowing the password and the final hash, the only thing to do would be to find what value needs to be combined with the password to yields the final hash. However, due to the fact that the salt could be of basically any length and consist of basically any values and could be inserted basically anywhere in the password, well, brute-forcing is not advisable unless you have reason to believe you know the salt’s location and character set. Unless you are the NSA and have motivation, money, and computing power rivaled by none, brute-forcing a well-designed salt should be impossible.

Hopefully, I didn’t over-complicate the concept salts. If you want a one-sentence synopsis of this article, it would be: A salt is a string of random values added to a password, before its hashed is stored, to prevent attacks on the resulting hash should it be discovered.

For those seeking to utilize salts in their security systems, my advice is to use private salts with a large character set that are added to the password at an interesting spot. Personally, I would recommend adding the salt to both the beginning and end of the password (it’s easy to do and few people will have the resources to try attacking that), using a full 256 value character set, and making it at least 16 bytes in length. If this is not feasible, as a second choice, I would recommend adding the salt in the middle of the password (maybe after the second character or something), making the salt consist of values from across the entire ASCII character set, and making it 8 bytes in length.

For those seeking to break a salt, my advice is to spend your time doing something more beneficial, like trying to create your own scripting language…. in binary…. using only 0’s. If the salt is actually worth its salt (forgive the pun), you should stand no chance in hell of breaking it. Granted, most salts will not be uber-great and may just be four lower-case ASCII characters added to the end of the password, but (hopefully) this will be the exception. There are too many variables (the character set, location, and length) to account for in breaking the salt, it usually isn’t worth it. If you do have to break one, I would say that your best bet would be to simply try brute-forcing it linearly the same way you would anything else, assuming the salt is on the end since that’s the laziest way to do it, and thus probably the way most of them are done. However, do NOT try a dictionary attack on the salt — salt’s are specifically chosen to be random and are usually double checked to ensure that they look like they are random. Thus they have a very, very low probability of being anything you would find in a dictionary, and actually will probably not be anything you could find there.

For the admins out there, no matter what system it is that you’re running, be sure that you’re dealing with tasty passwords. And, if possible, use your profound knowledge on salt to stimulate fun and casual conversation at the next cocktail party.

Note that password salting is not the same thing as message signing, in which one will hear the term “cryptographic signing” and of the algorithm HMAC. These are for using a private symmetric key to cryptographically sign a message, which is a different problem (even if it sounds similar in concept).