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?

Solution 1

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.

Solution 2

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.

Solution 3

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.

Solution 4

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.

Solution 5

The point of a salt is to render all rainbow tables useless and require a new set of them to be made. It takes just as long to guess a string as to make a rainbow table. For example the SHA-256 hash of "password" is 5e88 4898 da28 0471 51d0 e56f 8dc6 2927 7360 3d0d 6aab bdd6 2a11 ef72 1d15 42d8. After a salt is added, such as "badpassword" the new string to be hashed is "passwordbadpassword" which, due to the avalanche effect, dramatically changes the output, to 457b f8b5 37f1 802e f9c8 2e46 b8d3 f8b5 721b 7cbb d485 f0bb e523 bfbe 73e6 58d6.

Normally the salt is just stored in the same database as the password, also because if one database is hacked, it is likely that the other will be, also.

View more solutions

Comments

[jrockway]

If there's a place where you can store the salt that the attacker can't get at, then you should just store the passwords there too. But why not use a different salt for every password?

[Amber]

He is using a different salt for every password, jrockway.

[sourcenouveau]

How large are your salts? Your salts should be large enough (32 bits?) that there's practically no chance that a rainbow table has been precomputed for it.

[friedo]

@emddudley these days I've been in the habit of using a 64-bit integer as the salt, but there's no reason I can't make them longer.

[jcolebrand]

I would also like to toss this Database Administrators Q into the mix dba.stackexchange.com/questions/7492/…

[thashiznets]

Author of PWDTK here sourceforge.net/projects/pwdtknet , honestly I wouldn't worry and I would just store salt in the same DB as password. You should always assume salt is known to an attacker anyway so your focus should be on using a LARGE CRYPTO-RANDOM salt and performing enough key stretching (iterations in PBKDF2) so that making even one rainbow table for one known salt is infeasible. Honestly what you are trying to achieve by putting the salt elsewhere is "Security by Obscurity" and generally serves no benefit when you look at things such as another server to potentially go down.

[Pacerier]

@friedo, Salt alone is not enough. Use pepper.

[Pacerier]

@thashiznets, It's not security by obscurity if we're talking about peppers. It's security by password.

[thashiznets]

@Pacerier pepper is essentially a global salt, the question talks about hiding the salt which really your password scheme should be good enough such that even if they have the salt it will take them too long to make a rainbow table. However, there could be a small amount of merit in doing it to protect from idiot users using password as their password or something.

[Adam]

Agreed. The threat model you're protecting against by storing the salt separately is a user who can somehow access the salt in the DB through nefarious means, but not the hash (in the DB). And that that person will start computing a rainbow table in advance, assuming he will be able to find the hash later. Not impossible, but also not worth the engineering effort for defending aginst this single attack avenue.

[jigzat]

Nice post, I was wondering the same thing. I never thought about a salt per user I was thinking that a single salt would work for all users. What about a salt that is stored as an XML file that is loaded by the App Server? or maybe somehow hardcoded into a servlet?

[Amber]

@Jigzat - Salting is pointless if you don't have a separate salt for each user. The point of salts is to make breaking the hashes a separate task for each user password; if the salt is the same for all of them then that's not the case.

[mghaoui]

But what happens if all the hashed passwords are leaked including their matching salt? Isn't that just as insecure?

[Franklin]

@mghaoui But then if you wanted to know the "password" you still would have to construct a Rainbow Table for each and every salt, unless some of the salts are the same.

[chacham15]

@TomRitter thats not the only case. you assume that all of the passwords are complicated. some attackers may take the salt and hash and check only the 10,000 most common passwords. that way they will get a decent number of people. if, however, they dont have access to the salt, that is akin to the user having a longer more secure password. now, how likely is it that the salt database will stay safe while the password database is stolen is up for debate, but thats a separate issue.

[martinstoeckli]

With your approach you are just adding a secret to your hashing process (the algorithm that applies the salt). This secret you can add much easier with adding a pepper additionally to the salt, i tried to point this out in my tutorial. Modern hash functions like BCrypt will apply the salt on their own, using the original salt in each iteration, so you would have no control over this anyway.

[PeterToTheThird]

@martinstoeckli While you are correct that BCrypt applies the salt on their own, the storage of that salt+hash is up to you as the developer. So, you could easily add a pepper to the salt+hash and persist it to the database. Then, on subsequent retrieval, you read the value from the database, strip the pepper value, and pass the remaining value to BCrypt.

[martinstoeckli]

@PeterToTheThird - This would negate the advantage of the pepper. The pepper adds a server side secret, and only works as long as it stays secret (opposite to the salt). A typical attack is SQL-injection, when someone gains access to the database but not to the code, a pepper stored in the database will be useless then. Most BCrypt implementations will add the salt automatically to the resulting hash-value, so this value already contains the salt, the cost factor, the algorithm and the hash. This string can be stored in a single field of 60 characters length.

[Ibraheem]

To add, when using a "key strengthening" function such as BCrypt, you don't have control over usage of the salt. However, if you wanted to use a pepper you'd just append the pepper to the salt, and use that as a "peppered salt" in place of the "salt" input to the hashing function. The "pepper" then is a suitable piece of data that is not stored in the database, but embedded in the authentication code, or stored in another secure location. I approached the problem from a generic perspective, using SHA-512 as an example function, but BCrypt etc. can also be used in a similar way.

[martinstoeckli]

@Ibraheem - Actually a pepper should be combined with the password, not with the salt. Otherwise functions which return the salt in the resulting hash-value, would return the combined salt-pepper. You probably thought about functions where you have to store the salt separately.

[Ibraheem]

@martinstoeckli - yes, the actual implementation depends on which hash function you use. Obviously you need to take the parameters and outputs of the hash function into consideration when implementing your authentication logic. Ultimately, a pepper is just another variable introduced into your hashing function, that is not stored in the same location as the salt and hash.

[Cypher]

This does not increase security by any means. If I can download your database, I can download / reverse engineer your application code. Security through obscurity? Not really.

[Ibraheem]

@Cypher, whilst that is technically possible, to extract that information from the database if you had the data available would be practically impossible, which is the whole point of this approach - decrease the practicality of attack.

[Cypher]

I disagree, hence my down-vote. This does not increase security by any means.

[Ultratrunks]

@Amber, I believe TomRitter is correct. Storing the salt separately means the difference between forcing an attacker to use a brute force attack versus an easier dictionary attack. If you know the salt, you can just append it during a run of the mill dictionary attack. If you can 100% defend your salt, you can simply use the same salt and force attackers to brute force everything (even for users who use "password" as their password). But can you defend your salt.... probably not. So might as well reduce points of failure by storing it next to the hash and enforce stronger password rules.

[Aaron R.]

@Jigzat salting isn't pointless if you don't have a separate salt for each user unless your salt already has a widely distributed rainbow table and everyone already knows which one to try. More likely is if they get your salt, they will have to regenerate another table just for your stuff It'll slow them down, anyway. It still doesn't beat having different ones for each, of course.

[Amber]

"Regenerating a separate table" is the same effort as brute-forcing a single password. The point of salts isn't to prevent brute-forcing single passwords, so there isn't really much in the way of effective gain by having a shared salt. You might as well just not use salts and just hash your passwords in a slightly different way than everyone else, if you were going to do that. (But don't - use individual salts, because that's the actual secure way.)

[doliver]

@Amber, I think you might be missing something here. When you know the salt the number of passwords that you have to brute force is substantially decreased right? Because you already know most of the password (assuming the salt is longer than the user's password) and so the size of the rainbow table is substantially smaller. If the salt is hidden the size of the bruteforce it seems to me would be infeasible because you would have to create a rainbow table containing hashes of every possible salt assuming that you can't get the hidden salt.

[doliver]

I'll add that a more sound strategy would definitely be to use a stronger hashing function rather than relying on a hidden salt to protect you against brute force attacks so the outcome is the same.

[Muhammad Umer]

webdevelopment course on udacity by cofounder of reddit goes over this as well, and that was first time i learned it and i understood it right then too.

[Nick Coad]

@doliver since both methods are just as unlikely to be successful in any reasonable timeframe, I think the argument is purely academic and that in practice there's no real-world benefit to hiding the salt.

[John Ernest]

If the application can authenticate to both databases though, isn’t it essentially the same as if it were one database, if the attacker has compromised the application code?