Salted Passwords

Question

I have been reading on correct procedures for storing and checking user passwords, and am puzzling a little with salts.

I get the idea that they are to prevent use of such tools as rainbow tables, but to me the idea of storing the salt along with the hash seems a potential security problem. Too much data in one place for my liking.

The idea I have that I would like to run by folks is to use a 'lucky number' to create a salt from a portion of the password hash. Basically, along with choosing a password, a user would choose a 'lucky number' as well. This number would then be used as the starting index to retrieve a salt from the hashed pass.

So a very basic example would be something like this.

Pass = "Password"
Lucky Number = "4"
Pass Hash = "00003gebdksjh2h4"
Salt Length = "5"
Resulting Salt = "3gebd"

My thinking is that as the 'lucky number' would not need to be stored, the salt would then also take computational time to work out and so make any attacks even more difficult. Plus means storing slightly less data.

It wouldn't add more security - the most overwhelming calculation is actually finding the string mapping to a hash. Your computation is constant-time, which is nothing compared to that. It's enough to have distinct (or practically distinct) but not trivially simple ("1", "2", ... etc) salt for each hash you calculate. — lared, Feb 09 '15 at 22:04
Thanks for the answer. This is what I am trying to really get my head around. I guess if the salt is fixed-length then it is just a case of stepping through the hash until you find the salt. But what if the salt length was a variable based on the 'lucky number' too? Would that still be a constant-time calculation? — sidjames, Feb 09 '15 at 22:10
Yes, the whole point of hashing is that rainbow tables are pre-computed for given set of dictionary word combinations and by using some gibberish in salt you can't map hash back to password (unless it happens to also contain the salt), since it is also concatenated with salt, so with each new salt a rainbow table has to be recalculated, which is prohibitively expensive. Dictionary attacks still work, though (and that's why using nicks alone as salt is in general a not-so-great idea - they are often words you can find in a dictionary). — lared, Feb 09 '15 at 22:16
You're welcome. I've posted an answer so that if you want to you can close the question. — lared, Feb 09 '15 at 22:31

score 0 · Accepted Answer · answered Feb 09 '15 at 22:31

It wouldn't add more security. The goal of using rainbow table is to have a map of combinations of dictionary words and relevant hashes. By using a more-or-less distinct salt (which in general shouldn't be found in a dictionary) for each password hash you compute, you force the attacker to generate a new set of rainbow tables for each entry, which would be prohibitively computationally expensive. At no point (except for generating the hash table) the attacker calculates hashes, so your strategy fails here.

On the other hand when using a regular dictionary attack the attacker only needs a constant-time computation to calculate the salt, which he would have to compute only once for many millions or more combinations of hashes he would have to generate. It would only work if it was more computationally expensive than generating all that, but then you'd have to make the same computation each time a user wants to log in, which is not feasible.

Salted Passwords

1 Answers1