Where do you store your salt strings?

Question

I've always used a proper per-entry salt string when hashing passwords for database storage. For my needs, storing the salt in the DB next to the hashed password has always worked fine.

However, some people recommend that the salt be stored separately from the database. Their argument is that if the database is compromised, an attacker can still build a rainbow table taking a particular salt string into account in order to crack one account at a time. If this account has admin privileges, then he may not even need to crack any others.

From a security perspective, is it worth it to store salts in a different place? Consider a web application with the server code and DB on the same machine. If the salts are stored in a flat file on that machine, chances are that if the database is compromised, the salts file will be, too.

Are there any recommended solutions to this?

Answer 1

Often, they are prepended to the hash and stored in the same field.

There is no need to store them separately - the point is to use a random salt for each password so that a single rainbow table can't be used against your entire set of password hashes. With random salts, an attacker must brute-force each hash separately (or compute a rainbow table for all possible salts - vastly more work).

If you had a more secure storage location, it would make sense to just store the hashes there.

Answer 2

Based on Developing ASP.NET MVC 4 Web Applications book by William Penberthy:

1. Getting access to the salts stored in a separate database requires hackers to hack two different databases to get access to the salt and the salted password. Storing them in the same table as the password, or even another table of the same database, would mean that when hackers gain access to the database, they will have access to both the salt and the password hash. Because security includes the process of making hacking into the system too expensive or time-consuming to be worth it, doubling the amount of access a hacker would have to gain should make the system more secure.
2. Ease of use is the primary reason for keeping the salts in the same database as the hashed passwords. You would not have to ensure that two databases are always available at the same time, and always in sync. The advantage of having a salt is minimal if each user has a randomized salt because although it might make discovery of an individual’s password easier, the amount of force necessary to crack the passwords of the system overall will be high. In this level of discussion, that is really what the expectation is: to protect the passwords. If the hackers have acquired a copy of the database, your application data is already compromised. At this point, the issue is to mitigate users’ risks because of the potential of shared passwords.
3. The requirement of maintaining two separate linked, databases is extensive. Granted, it adds the perception of security, but the only advantage that it gives is that it protects a password, a single element of data. If every field in the database were individually encrypted, and this same salt was used for that, it would make more sense to store it separately from the data because the basic security of your system is enhanced.

Answer 3

The point of rainbow tables is that they're created in advance and distributed en masse to save calculation time for others - it takes just as long to generate rainbow tables on the fly as it would to just crack the password+salt combination directly (since effectively what's being done when generating rainbow tables is pre-running the calculations for brute-forcing the hash), thus the argument that by knowing the salt someone could "generate a rainbow table" is spurious.

There's no real point in storing salts in a separate file as long as they're on a per-user basis - the point of the salt is simply to make it so that one rainbow table can't break every password in the DB.

Answer 4

I will provide a slightly different take on this.

I always store the salt mixed in with the salted-password hash.

For example, I will place the first half of the salt before the salted-hash of the password, and the last half of the salt after the salted-hash of the password. The application is aware of this design so can fetch this data, and obtain the salt and salted-password hash.

My rationale for this approach:

If the password/hash data is compromised and falls into the hands of an attacker, the attacker will not know what the salt is from looking at the data. This way an attacker cannot practically perform a brute-force attack to obtain a password that matches the hash, since he doesn't know the hash to begin with and has no way to know which parts of the data are parts of the salt, or parts of the salted-password hash (unless he does know your application's authentication logic).

If the salted-password hash is stored as-is, then a brute-force attack can be performed to obtain a password that when salted and hashed produces the same data as the salted-password hash.

However, for example, even if the salted-password hash was stored as-is, but pre-pended with a single random byte, as long as the attacker is unaware that this first byte is to be discarded, this would also increase the difficulty of attack. Your application would know to discard the first byte of the data when used to authenticate your user.

The conclusion to this..

1) Never store the data that your authentication application uses in it's exact form.

2) If possible, keep your authentication logic secret for added security.

Go one step further..

If you cannot keep your application's authentication logic secret - lots of people know how your data is stored in the database. And suppose you have decided to store the salted-password hash mixed in together with the salt, with some of the salt prepending the salted-password hash, and the rest of the salt appending it.

When generating the random salt, you could also randomly decide what proportion of your salt you will store before/after the salted-password hash.

For example, you generate a random salt of 512 bytes. You append the salt to your password, and obtain the SHA-512 hash of your salted-password. You also generate a random integer 200. You then store the first 200 bytes of the salt, followed by the salted-password hash, followed by the remainder of the salt.

When authenticating a user's password input, your application will pass over the string, and assume the first 1 byte of the data is the first 1 byte of the salt, followed by the salted-hash. This pass will fail. The application will continue by using the first 2 bytes of the data as the first 2 bytes of the salt, and repeat until a positive result is found after using the first 200 bytes as the first 200 bytes of the salt. If the password is wrong, the application will continue to try all permutations until none are found.

The pros of this approach:

Increased security - even if your authentication logic is known, the exact logic is unknown at compile-time. It is practically impossible to perform a brute-force attack, even with knowledge of the exact logic. Increased lengths of salt will increase security further.

The cons of this approach:

Since the exact logic is inferred at run-time, this approach is very CPU-intensive. The longer the length of the salt, the more CPU-intensive this approach becomes.

Authenticating incorrect passwords will involve the highest CPU cost. This can be counter-productive to legitimate requests, but increases security against attackers.

This approach can be implemented in various ways, and can be made even more secure by using variable-width salts and/or salted-password hashes.