0

I have a question about password hashing. This is not a question about the the BEST POSSIBLE method of hashing passwords, but rather a more utilitarian question about what is sufficient to hash a password without standard rainbow tables being an issue.

Let me outline a hypothetical scenario. You have an application that is designed without unique salts, and for whatever design reasons, it would be a huge modification to change the application to work with a unique salt for each individual user. So instead of rewriting a huge part of the application, we are looking for a way to hash passwords that is more secure than a pure SHA1 (or whatever standard hashing algorithm), but doesn't involve unique salts.

I'll give two examples of solutions that don't involve unique salts. They each have the obvious advantage of rendering a rainbow table for a pure SHA1 (or any other standard hashing algorithm) useless. Each does, however, have the disadvantage of being able to create a rainbow table for that particular strategy. But if you think about it, using a unique salt has the same vulnerability, if you were to target a single user.

The simplest idea is to have a single salt for all passwords hard-coded. The second is to come up with a more complicated algorithm, such as splitting a password in two by a defined set of rules, hashing each, then hashing the concatenation of the two partial hashes and store that. This can be extended to any algorithm you like.

Is this method sufficient for most applications? Neither is obviously as secure as a unique salt for each user, but if you were targeting a specific user it seems neither more nor less secure if you know the salt for that particular user.

Is that correct? And is it a viable solution for some (or maybe most) cases?

Improve this question
1
  • 1
    Whether your hashing scheme is sufficient you will find out as soon as your hashes where stolen, then you will have to contact your customers, and tell them that unfortunately their passwords are not well protected. I cannot imagine a modification so huge, that it is worth the risk. Every hashing scheme must be able to change to more secure standards from time to time, this is not only a one time job.
    – martinstoeckli
    May 1, 2014 at 11:16

4 Answers 4

Reset to default
2

The rationale for unique salts is not simply to combat rainbow tables. If your entire database of passwords is hashed without salts (or with only one salt), then an attacker can attack your entire password database simultaneously instead of being forced to attack each password individually.

Also, as mcdowella has pointed out, a password database which is not protected by unique salts can potentially fall victim to an attacker extrapolating information from the fact that multiple users are observed to share the same password.

Neither of your solutions address either of these problems. You can make the attack more expensive computationally by using something more secure than sha1 (a high itteration count PBKDF for instance) but that isn't a replacement for unique salts. They are easy to implement and the cost/benefit ratio of unique salting in terms of additional computation time and increased difficulty to attack is better than pretty much any other single approach.

Improve this answer
2

Please first read up on the normal ways to do password hashing and on the use of Pepper. Then you should consider whether you really cannot store any information alongside the hash in your database e.g. in the way mcdowella has suggested. If you have proper Pepper in your hash then your salt does not have to be random but just different for every password change. For example use the current time in millisecond as well as the account ID to generate the salt (you can concatenate them or even hash them once with SHA* if variable length is a problem for your database). If for some reason you can't store anything but the hash at least include the account id as salt in your password hashing scheme. And as always with password hashing: Use a slow hash function (except for the above idea for salt generation).

Improve this answer
1
  • Don't know why I never considered using the account ID as a unique salt (or at least to generate a unique one). That doesn't require any modification to the code. I'll read up on Pepper. Thanks.
    – Ryan Williams
    May 1, 2014 at 16:10
1

One problem with an algorithm that does not have unique salts is that two users with the same password will hash to the same value. If one user sees this they know the other password. If an outside attacker sees this they have a hint that the users have chosen a common - and therefore weak - password. Can't you use a unique salt and store it formatted as part of the hashed password? E.g. store "SALT#HASHVALUE" as the hashed password.

Improve this answer
0

Sorry to answer my own question so soon, but Stackoverflow had some good suggested answers. As you might expect it all comes down to computation time. If you use an algorithm that takes a second to run to hash a password you can multiply that my millions to come up with the computation load on a machine trying to generate a rainbow table for your algorithm. So I guess, with or without unique salts, you should create as many steps as possible to hash a password without any huge load on your server. You can run your input through the same algorithm recursively 1000 times. You can get more complicated than that. It all comes does to how much computation it takes to hash an individual password.

Improve this answer

You must log in to answer this question.