Salting Passwords - How Do You Store Them?

James

Well-known member
As the title states, how do you store the salts for your passwords?
Some people generate and store salts in the filesystem, whereas others store salts in the database.

Where do you store your salts and why?
 
Every user gets its own salt.
Indeed. Take vBulletin as an example; every user has a unique salt but this salt is stored in the database along with the password hash. Some people consider this to be useless if the database is compromised.
 
For the app I recently coded I did sha256(sha256($pass).$global_salt). The salt was stored in the filesystem. :)

Not saying this is the best way to do it. It was good enough for me, though. :)
 
Some people consider this to be useless if the database is compromised.
It might seem useless at first sight, but actually it's not. :)

The salting of user passwords is done to prevent(?) recovery of the original password from the stored hash. Salting makes rainbow table attacks against the hashed passwords quite difficult as the entire table has to be regenerated for each and every salt in the database to make the attack feasible.
 
I was just thinking about this and a really simple salting method came to mind:
PHP:
// obviously declare variables first blahblah

$usernameLen = strlen($username);

$pwdSalt = sha1($username . $password . $usernameLen);
Something that can be filesystem stored and the salt will differ based on the length of the username. This is obviously a very simple salting method, however the salt would change depending on the username length.

@Shadab,
Yes, but if the salt is alongside the passwords hash and the hashing algorithm is known then the process is a hell of a lot easier for the bruteforcer.
 
$pwdSalt = sha1($username . $password . $usernameLen);
Wouldn't this make the salt somewhat predictable though? I mean anyone can get the username and username length, so they might as well not be there, right? :)
 
Wouldn't this make the salt somewhat predictable though? I mean anyone can get the username and username length, so they might as well not be there, right? :)
If someone knew the algorithm yes it's predictable.
You could *10 /2 + 11 * 1.57 - 1 if you wanted to. It works the same way as any other salt, only the salt isn't visibly stored in the database alongside the password hash. It means a user has to break into your filesystem AND your database to get what they need and that's an added layer of security IMO.
 
Yes, but if the salt is alongside the passwords hash and the hashing algorithm is known then the process is a hell of a lot easier for the bruteforcer.
I agree that it gets easier to break if you have both of them stored in the same place. But IMO, the main purpose of salting is to transform the insecure password of your average Joe to something that is hard to recover.

Suppose my password is qwerty. It's SHA-1 hash is: b1b3773a05c0ed0176787a4f1574ff0075f7521e, for which you can very easily find a collision in your multi-billion record rainbow table. ;) If I append a salt to that password: euHbjV6wHK, the hash changes to: d46d1f71d5030ff5cc007577ff880d99906971f8 and it would no longer match anything in your table, effective making it useless.

To even stand a chance at finding a collision now, new tables have to be generated taking into account this salt. And if you have separate salts for each user (no matter if they are stored right in the database), such attacks are no longer feasible as you have to keep regenerating the tables for each user in the database. :)
 
I agree that it gets easier to break if you have both of them stored in the same place. But IMO, the main purpose of salting is to transform the insecure password of your average Joe to something that is hard to recover.

Suppose my password is qwerty. It's SHA-1 hash is: b1b3773a05c0ed0176787a4f1574ff0075f7521e, for which you can very easily find a collision in your multi-billion record rainbow table. ;) If I append a salt to that password: euHbjV6wHK, the hash changes to: d46d1f71d5030ff5cc007577ff880d99906971f8 and it would no longer match anything in your table, effective making it useless.

To even stand a chance at finding a collision now, new tables have to be generated taking into account this salt. And if you have separate salts for each user (no matter if they are stored right in the database), such attacks are no longer feasible as you have to keep regenerating the tables for each user in the database. :)
Indeed but it is still possible if you have the salt. The purpose of a salt is to add an extra security layer to a password hash but what would make it even harder is if someone was to grab your password hashes but not have the salt, they wouldn't even attempt to bruteforce them at this point :P
 
For the app I recently coded I did sha256(sha256($pass).$global_salt). The salt was stored in the filesystem. :)

Not saying this is the best way to do it. It was good enough for me, though. :)
This is ok as long as a hacker does not know the value of $global_salt. If he gets his hands on it, the whole salting renders useless because he will be able to easily generate dictionary to brute-force your passwords.
 
I usually salt them, leave them to mascerate overnight, then rinse the salt off before smoking over smoldering coals on the bbq.

Mmmmm tasty!
 
For the app I recently coded I did sha256(sha256($pass).$global_salt). The salt was stored in the filesystem. :)

Not saying this is the best way to do it. It was good enough for me, though. :)
You really need to add a per-user salt to that. And you should use a deliberately slow password hashing function instead of a general-purpose hashing function designed to be fast.
 
You really need to add a per-user salt to that. And you should use a deliberately slow password hashing function instead of a general-purpose hashing function designed to be fast.
I know, it's not the best design. I originally thought that sha256 was significantly slower than md5, but as you mention it turns out that it's still a fast hashing function.

Besides, this app is not very important and it's obviously too late to change the hashing method anyways. ;)
 
I realise the slower the hashing process = the longer it takes to crack them, but do we really need slow hashing processes if we use a decent hashing algorithm? Use a per-user salt and a global salt and it's going to be pretty difficult to crack your hashes anyway. Remember that the faster we can hash a password and compare it, the faster our login process works.
 
I realise the slower the hashing process = the longer it takes to crack them, but do we really need slow hashing processes if we use a decent hashing algorithm? Use a per-user salt and a global salt and it's going to be pretty difficult to crack your hashes anyway. Remember that the faster we can hash a password and compare it, the faster our login process works.
The hashing function is a tiny, tiny part of the login process. If you slow it down by 2x, it won't have anywhere close to a noticeable effect on the login process. But now the rainbow tables take twice as long to generate. See the idea?

It's always a good idea to use expensive hashing functions, as it won't have an effect on daily logins but will make it take much longer to generate rainbow tables and crack your passwords - unless the cracker is targeting your site specifically, he'll probably just move on to the next target as your site isn't worth it. :)
 
Top Bottom