Do salts have to be random, or just unique and unknown?

Question

First of all, my objective is to avoid storing the salt in the database as plain text. As far as this question is concerned, the salt is not stored in the database.

After discussion in comments and in chat, I've come up with a theory:

It appears that using domain_name + user ID alongside a pepper will provide a sufficient combination of randomness and uniqueness.

Would a method such as this provide just as much security as a random salt without having to store a designated salt in the database as plain text?

Answer 1

The only requirement of a salt is to be globally unique. It doesn't have to be random and it most certainly does not have to be unknown.

Note the keyword globally. A salt must be unique not only in the context of your database, but in the context of every single database out there. An email or an incremental user ID is (very) unlikely to fulfill this requirement. Using a randomly-generated salt does.

EDIT

I'm going to address the whole using a domain + userid as a salt idea that came up in the comments. I do not think this scheme is a good idea especially when compared with just using a random salt.

If your site is a high target one, an attacker might find it worthwhile to generate a rainbow table targeting the admin account before the attack occurs. This might allow him to get access before the attack gets discovered. The domain + userid scheme does not work well when you consider this situation because the admin account is usually within the first few userids in the system especially when userid is incremented using a counter.

That being said, this whole discussion is really moot in practice. Generating random salts is easy and fast. Many password hashing libraries, especially the bcrypt ones already do it for you. There really isn't a point in rolling your own scheme even if it's just as secure. Let's face it, we are all lazy people aren't we? :P Why reinvent the wheel?

Answer 2

The important feature of a password salt (as Terry Chia correctly notes) is that it should be globally unique: no two password hashes (even on different sites) should ever have the same salt.

Using unique salts protects against various related attack methods that might be employed by an attacker who has compromised the user database and wants to recover the passwords from their hashes:

• First of all, it prevents an attacker from easily telling if several users have the same password (which would make those users obvious target, since such a common password would likely be easy to guess and provide a high payoff).

• Conversely, it also prevents an attacker who has compromised multiple sites from being able to easily tell which users have used the same password on both sites.

• Further, using a unique salt for each user prevents an attacker from obtaining any benefit from attacking multiple accounts at the same time. Without salts (or with non-unique salts), an attacker could hash a guessed password and then compare it against every password hash in the database, making it more likely that they'll obtain at least one match. With unique salts, this is impossible, since the attacker has to choose the salt (and thus a single target user) before hashing each password guess.

• Finally, unique salts also make it impractical to use precomputed hash look-up tables (like the so-called "rainbow tables") to speed up password cracking, since, essentially, a separate table would be needed for every user.

Basically, the main goal of salting is to ensure that an cracking multiple compromised password hashes together should be no easier than cracking each one of them separately — nothing more and nothing less. Using globally unique salts achieves this goal.

---

One easy way to ensure global uniqueness (with high likelihood) is to use a sufficiently long random string as the salt. However, other ways exist too.

For example, you could obtain a globally unique salt by combining a locally unique user identifier (such as an e-mail address or an account number) with a fixed, globally unique site identifier (e.g. the domain name of a website), and possibly some other items like a purpose designator (in case you might need more than one unique salt per user) and a timestamp (so than a new password will always get a different salt). For example, the following string would be perfectly good globally unique salt:

"This is a password salt for user 5457 on security.stackexchange.com created at 1 September 2013 13:35:23.94730 UTC"

and so would this one too:

"password_salt:5457:security.stackexchange.com:20130901T133523.94730"

If you'd prefer your salts to be more compact, you could also feed either of the strings above through a cryptographic hash function like SHA-256 and use the output as the salt. Or, if your system provides a built-in GUID generator, you could just use that (assuming that it works as it should, of course).

---

All that said, there is one potential benefit to making password salts not only unique but also unpredictable: it prevents the attacker from starting a brute-force attack before they've compromised your database.

Basically, if I, as an attacker, knew that your admin account's salt was, say, "12345678", then I could set my computer(s) to compile a lookup table of more or less common passwords hashed with that salt even before I'd found a way to obtain your actual password hash. Once I did find a way to do that (maybe weeks or months later), I could look up the hash in my table, hoping that it might match one of the passwords my program had already tried in the mean time, in which case I would know the password immediately.

However, if I didn't even know what the actual salt you used was, I wouldn't be able to start guessing the password before I first obtained the correct salt. That would take extra time, potentially allowing you to change the password before I managed to crack it.

Again, long random salts are (with high probability) not only unique but also unpredictable. That said, there are other ways to achieve this goal, too. For example, you could take either of the unique example salts shown above and just append some secret value (e.g. a random string stored in a config file, possibly changed regularly) to it. Since this secret would be the same for all users, it wouldn't help with uniqueness, but it would ensure that I wouldn't be able to start a brute-force attack without first somehow learning the secret.

---

Addendum: Regarding your edits to the question, I'd say that your scheme (using domain name + user ID + pepper as the salt) should be enough. If possible, I'd also include a timestamp, but that obviously requires you to store the timestamp somewhere.

That said, I still find your premise ("the salt is not stored in the database") a bit puzzling. If you can store the password hash itself in the database, why not the salt too?

In fact, many common password hashing schemes don't use a separate database column for the salt at all, they just store it as part of the hash string, e.g. as method$salt$hash, where method identifies the hashing method used, salt and hash are the salt and hash values encoded using some suitable scheme (e.g. base64) and $ is just an arbitrary separator character that doesn't occur in the encoded salt or hash.

Answer 3

A salt is supposed to be unique, must be long enough, and should be unpredictable. Randomness is not necessary, but it is the easiest way for a computer to meet those requirements. And it is not the purpose of a salt to be secret, a salt fulfills its purpose even when known.

Uniqueness means that it should not only be unique in your database (otherwise you could use a userid), it should be unique worldwide. Somebody could create rainbowtables for salts like e.g. 1-1000 and would be able to retrieve passwords for all accounts with those userids (often admin accounts have low userids).

Long enough: If the salt is too short (too few possible combinations), it becomes profitable again to build rainbow-tables. Salt and password together can then be seen as just a longer password, and if you can build a rainbow-table for this longer passwords, you also get the shorter original passwords. For very strong and long passwords, salting would actually not be necessary at all, but most human generated passwords can be brute-forced because they are short (people have to remember them).

Also using salts derrived from other parameters can fall into this category. Only because you calculate a hash from the userid, this doesn't increase the possible combinations.

Unpredictability is a bit less important, but imagine once more the case that you use the userid as salt, an attacker can find out what the next few userids will be, and can therefore precalculate a narrow number of rainbow-tables. Depending of the used hash-algorithm this can be applicable or not. He has a time advantage then, can retrieve the password immediately. More of a problem will be, if the admin accounts used a predictable salt.

So using a really random number, generated from the OS random source (dev/urandom), is the best you can do. Even when you ignore all reasons above, why should you use a derrived salt when there is a better way, why not use the best way you know?

UPDATE: to answer the changed question:

Using only domain_name + user_id to generate the salt is surely not a good idea, because it can be guessed and makes it predictable. A pepper won't help here, because it is as constant as the domain_name, you should not rely on it to be secret. With the user_id you gain uniqueness, with the domain_name you get global uniqueness, but you are missing the unpredictable part.

In your previous example you added the password itself as random parameter like salt = hash(domain_name + user_id + password). This could work as long as the salt won't be stored at all, to verify the password you would have all necessary parameters. I cannot see a flaw in this concept, but this doesn't mean that i recommend it. As already mentioned, you cannot do better than generating a random independend salt. Adding this salt to the hash and extracting it for verification is not a hard job, most appropriate hash functions will already do it for you, because they also have to store the cost factor in the same way.

Answer 4

First of all, my motive is to avoid storing the salt in the database as plain text.

Why? There is no good reason to avoid storing the salt in the database in plain text. This is how a salt is normally stored.

With the various iterations of your question, you've proposed various ways to do things differently, but they all either end up having the same security properties, or (usually) make things worse.

The point of a salt is to prevent attackers from sharing the work when cracking many accounts at once. Often attackers are not after a particular user on a particular site, what they want is to get a foothold or to crack as many accounts as possible. The point of salt is to make cracking Joe's account on the ACME site require completely different computations from cracking Jane's account or Joe's account on the Yoyodyne site. Hence the need for a salt to be globally unique: across accounts, and across databases (and even across time).

If you use the password as part of the salt calculation, it isn't a salt at all. The salt needs to be independent from the password. If you calculate the salt from the password, then it becomes part of the hash function: H(S(P),P) is a function of P, you've only created a new hash function H'(P) = H(S(P),P).

Using the user name is not good because it can be the same across databases. An attacker with the ACME database and the Yoyodyne database can crack both databases without duplicating the effort if they use salt that is derived from the user name.

If you use the domain name and the user ID, that can work. Make sure that no one else in the world who uses the same domain name; in particular, don't use the same domain name if you have more than one subsite: include the service name or whatever it takes to make the name unique. Also, don't reuse user IDs. As long as your salt is globally unique, it's a proper salt.

Note however that you will not gain any security from using the domain name and user ID as the salt rather than a random salt as is typically done. The salt is still effectively stored in the database, just in some weird way. You save a few bytes per database record, which shouldn't be significant.

A pepper does not significantly improve security either. You cannot assume that your pepper remains secret. If the attacker has been able to obtain a copy of your password database (typically by compromising your application or by gaining access to a backup), it's likely that they also have access to the pepper (it needs to be accessible to the application and backed up, after all). The only case where a pepper is useful is a compromise such as SQL injection which only grants the attacker access to the database and does not extend to an application compromise, not even via an administrative account. Don't count on it. Even if you use a pepper, your salt must be globally unique.

I strongly recommend generating a random salt and storing it alongside the password. Preferably, don't code it up yourself: use an existing library that does it right. The more you deviate from recommended practice, the more you risk doing it wrong — perhaps completely, dangerously wrong like deriving the salt from the password.

Remember that in addition to be salted, password hashes must be slow. That means PBKDF2 or bcrypt or scrypt, with an iteration count adjusted for current computer speeds.

For more background, read our numerous threads on this subject:

• How to securely hash passwords?
• How to store salt?
• Password Hashing add salt + pepper or is salt enough?
• When hashing passwords, is it ok to use the hashed password as the salt?
• Why is using salt more secure?
• Don't be a Dave: Is my developer's home-brew password security right or wrong, and why? (Hint: no.)

Answer 5

Since none of the other answers seem to touch on this:

DO NOT use part of the password as the salt. In addition to decreasing unpredictability, it will, when an attacker figures it out, help an attacker break the passwords. Why? Because they have part of it right there, next to the password in the database.

Update: If you are using part of the password in the salt, and you want to avoid having to store the salt, then pulling part of the password after it's entered to calculate the salt will work well. It further complicates brute forcing, and it's just as effective as a regular salt at increasing entropy. It makes rainbow tables a bit harder to make, as you need to calculate the salt per password, but it doesn't really prevent them any better than a regular salt.

Answer 6

In addition to @terry-chia's outstanding answer there is another reason to pick random salts. The hashing and authentication scheme that you are using today may place relatively weak requirements on salting, but someday you might (or a successor) might modify the scheme used in a way that does have a randomness requirement.

So although randomness isn't a requirement, you are far safer if you do pick random salts, as that will guarantee that you get all of the things required for your scheme today, but it will also provide you with what you may need tomorrow.

Again, an additional, reason on top of what others have already explained. Do not derive the salt from user data! Using a random salt may get you more than you need, but it will ensure that you don't make other errors. You have nothing to gain in not using a random salt (unless there is something you haven't explained yet), while you make your system far less robust by just going for the minimal requirements of a salt.

Answer 7

Any salt whatsoever improves your security. Without a salt, an attacker could identify all 1,000 accounts with password 123456. They wouldn’t know the password but they would know it’s very, very common and most likely easy to crack. So that’s a bullseye. If these 1000 accounts all use different salts except for two equal ones, then 998 give no clue to the password strength and will not be targeted. Two give a clue, but cracking them gives the attacker only two passwords, not 1000.

If you create a long, random salt then it is very unlikely to be used by someone else. And if your password is secure then it is also highly unlikely that someone has the same password, and double unlikely that both have the same hash value.

And if two users have the same hash by pure coincidence (different salts, different strong passwords) that is the worst case for the attacker. Because they think the password is weak and try to crack it but fail and waste time because they are both strong.