Is it possible to attack a user password with known salt

Question

I've been told that email is a bad salt, because it's not unique and connected to the user.
And if a user uses the same password on 2 sites, there will be equal hash.

So, what's wrong with it? what is attack scenario?
Suppose we have both hash and salt. So, other site has the same hash in their database. How can we do any harm to this user on the other site? Can we at all?

I don't see any possibility, but I am not an expert in security, so, I'd like to hear from ones who are, with practical and concrete answers, of course.

I am not going to break anything. I am asking this question in the context of this one: is email or (registration timestamp) a good salt?

Certain and practical answers, please.

Answer 1

The point of a salt is not to be unknown, it is to prevent attackers from amortizing the cost of a brute force or dictionary attack across all users of a site (or even all users of many sites).

Thus, the problem of using a non-random salt like the email address is that it would show an attacker which users are using the same password on several sites, and which would therefore yield access to several accounts at once if cracked via brute force or dictionary attack. For the email address (and everything that is unique per user), this is a rather hypothetical problem since it assumes the attacker has the account data of several sites with considerable overlap in users.

Another problem with using the email address is that users will want to change it - which would be impossible if you use it as salt unless you store it in a separate salt column as well or require people to always change their password together with their email.

Answer 2

This is mostly a theoretical question. So, how does "cracking a hashed value" work? There are so called "rainbow tables", that are just list with common words and theire hash value. For salted hashes an attacker needs such tables also with salted hashes. So in theory with unique salts for every user an attacker needs one table for every salt (=> user). If you have a static salt, he "just" needs one table for your db. Its quite expensive to create such tables, so in most cases its not worth to create it just for a single page.

Conclusion: Its (of course) safer, to use unique salts for every user, but on a veeery high level. A static salts is usually "safe enough".

Answer 3

The first attack I can think of is:

• a user has the same salt and password at two sites
• both sites have a flaw to allow reading the salted passwords
• one site makes reading a password or brute-force guessing a password easy

An attacker could quickly look at identical salted passwords on both sites and find users with identical passwords at both sites. Then read the password or guess the password on the weaker site, and use it on the more secure site.

Granted, different salts wouldn't make the problem significantly better because all million passwords can be tried eventually. But knowing which users have identical passwords would be much 'quieter' than just blindly trying all the users' passwords on the stronger site.

Answer 4

Think of the web sites you've programmed - I bet the most powerful users in these systems have very common usernames like admin, root, etc. As an attacker I can generate a precomputed hash list containing the most common usernames with the weakest and most common passwords - that is, if a web programmer is naive enough to salt their passwords with usernames, my job as an attacker has become much, much easier - the collisions are very predictable.

Using an email address as a salt is better, but the same principle applies. Assuming I've cracked one database that uses an email-based salt I'll have a much easier time cracking every other database that does the same - at least, for email/password combinations that exist across databases. (Given the amount of login reuse, that's a very likely). It's not as simple as with the username salts, but the collisions are out there, waiting to be discovered.

As a programmer what I really want is a password hash that won't collide - ever. A universally unique hash for each user that can't be found in any other database in the world. That's a tall order, but it's doable with a sufficiently long, randomly generated salt.

There's a herd immunity effect in play - using a bad salt makes it easier for attackers to attack similar systems after they've compromised your database. A strong salt will always protect your users and help other userbases from being compromised.

Answer 5

Can't really help you in terms of security, but if you look at vBulletin for example, each user gets their own generated salt, which they use the encrypt the password like this:

$password = md5(md5($clear_password) + $salt);

So the salt will be different for each user and any site where vBulletin is running (at least a pretty good chance that it will be different), so the stored password, in turn will be different for each site.

It's not what you were asking for, but something to meditate on :)

Answer 6

Assume the hacker has both password and salt, AND access to your hashing formula.

This will NOT prevent a dictionary attack, contrary to popular beleif. It will stop a simple dictionary attack, but iterating the dictionary with the salts per user account is perfectly possible.

See: Why do salts make dictionary attacks 'impossible'? for more related information.

This is why when you generate the hash of the password, instead of hashing once with salt, IE:

hashedPW = sha1(rawPassword + salt)

You would do:

hashedPW = sha1(rawPassword + salt)
for i = 0; i < 2000; i++){
    hashedPW = sha1(hashedPW + salt)
}

The multi hash function should take a significant fraction of a second to calculate. This means when the hacker gains access to the database, the dictionary attack then becomes exponentially more time consuming only allowing him to crack a very small % of user accounts.

Answer 7

If the salt is already known, then you have bigger problems on your hands.

http://en.wikipedia.org/wiki/Rainbow_attack