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.Every user gets its own salt.
It might seem useless at first sight, but actually it's not.Some people consider this to be useless if the database is compromised.
// obviously declare variables first blahblah
$usernameLen = strlen($username);
$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?$pwdSalt = sha1($username . $password . $usernameLen);
If someone knew the algorithm yes it's predictable.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?
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.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.
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 pointI 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.
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.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.
Yes, but sha256 is a more expensive hashing function and it would take longer to generate the tables than md5.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!
Funny, I was reading the same article!Also, everyone should read this: http://chargen.matasano.com/chargen...to-know-about-s.html
Same.Found it referenced on CodingHorror. But since the original link was broken,
I had to search a bit to get to the actual blog post.
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.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.
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.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.
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?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.
We use essential cookies to make this site work, and optional cookies to enhance your experience.