Is it a good idea to use the user's username as a salt when hashing a password like hash(username_str + password_str)?

Question

I'm helping my friend with hashing his passwords, and I've a question - Should he use one secret string as salt for hashing or is it better to have each user its own salt for hashing?

Consider these three hashes:

hash("secretKey777" + password);
hash("secretKey777" + username + password);
hash(username + password);

Which one is the hardest to crack and the safest?

I think it's best to use hash("secretKey777" + username + password); because for each user not only has "secretKey777" as a salt but also its own username. In case code that hashes the passwords leaks, there will be no attack on all the hashes at once - each has will have its own unique salt.

Answer 1

The primary characteristic of a salt is that it should be globally unique for each user's password hash. It need not be secret, and a username will certainly not meet the required criteria of uniqueness. A shared secret string (used for all users) is not a salt, but a pepper, and has not been demonstrated to add any security over unsalted passwords, and so is not a viable option.

One construction that has the property of being particularly likely to be globally unique is random data of reasonable length. The salt doesn't actually need to be random, but a random value, generated individually for each user gives us reasonable assurance that we have the uniqueness we need.

There's a bit more in this answer: What should be used as a salt?

Answer 2

Someone had mentioned that the salt need not be secret, just unique across all applications and that a username doesn't meet that requirement.

My suggestion then is to use a combination of your domain name and the user's username as salt:

"example.comsomeuser777" This is both unique to the user and unique to the application.

Require the user to enter their password if changing their username.

Answer 3

Should he use one secret string as salt

No. One hard-coded side wide salt does prevent pre-calculated rainbow table attacks, but those are not really a major concern nowadays. The main advantage of using a random salt for each hashed password is that an attacker when bruteforcing has to hash each password with each salt, instead of just hashing once and checking against all passwords. So it slows the attack down by a factor equal to the number of users.

each user not only has "secretKey777" as a salt but also its own username

Don't use usernames as hashes. It doesn't really impact security[*], but it does have an effect on usability and maintainability. What if a user want's to change their username? This wouldn't be possible with your approach.

_{[*] except for the point @Xander made. It is an impact, but it is quite low.}

So what is the correct approach?

hash(password+ generateRandomSalt());

And store the salt next to username and password in the database. You could also use a library that manages all of this for you (for example if you are using PHP, password_hash uses bcrypt and manages the salts for you).

Answer 4

Other answers have addressed well the reasons why you should at least use a unique salt for each user. They seem less convincing on why that should not be the username.

Within the confines of a single system/site, the username will be unique, and might seem sufficient as a salt. There's indeed not any particular reason why it would be inadequate in that case -- except one: if you have some well-known usernames (like "root" or "admin") then you've lost the uniqueness property and you're vulnerable to rainbow tables again, defeating the main purpose of a salt.

However, that's not the only consideration. What happens if everyone starts doing this -- or even just a few popular sites?

The main problem with using a username as salt is that if multiple sites did this, and their hashes are leaked, it is immediately obvious when a user has used the same username+password across multiple sites and is thus a high-value target, because their hash only needs to be cracked once to gain access to all the sites. Crackers can and do compare leaked data from multiple sites, so you can't consider each one in isolation.

Using a random salt avoids this problem: even if someone did use the same username+password, the resulting hash will be different and not expose this property.

Regarding combining a (random) salt with both the username and password: this may be stronger than omitting the username, but only really by virtue of making the salt longer -- in principle (for salt+password alone) increasing the salt length by the username length would be even better. In practice, neither one makes much difference unless your salt wasn't long enough to begin with.

Answer 5

Assume that everybody uses this methods. And many users use the same username and password, and therefore the same hash, on multiple sites. And one site, totally unimportant by itself, is insecure and allows an attacker to download a list of usernames, passwords and hashes.

Now the attacker can visit all kinds of websites and try the username/hash combinations and will be able to login whenever a user also used that insecure site.

The goal should be that your hashes are different from the hashes on any other site. If you pick just one random salt for your application then you achieve this. But not with the username as the salt.