1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Salting Passwords - How Do You Store Them?

Discussion in 'Off Topic' started by James, Sep 3, 2010.

  1. James

    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?
  2. Floris

    Floris Guest

    Every user gets its own salt.
  3. James

    James Well-Known Member

    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.
  4. Erik

    Erik Well-Known Member

    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. :)
  5. Shadab

    Shadab Well-Known Member

    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.
  6. James

    James Well-Known Member

    I was just thinking about this and a really simple salting method came to mind:
    // 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.

    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.
  7. Erik

    Erik Well-Known Member

    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? :)
  8. James

    James Well-Known Member

    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.
  9. Shadab

    Shadab Well-Known Member

    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. :)
  10. James

    James Well-Known Member

    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
  11. Vladislav Rastrusny

    Vladislav Rastrusny Active Member

    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.
  12. Kim

    Kim Well-Known Member

    I usually salt them, leave them to mascerate overnight, then rinse the salt off before smoking over smoldering coals on the bbq.

    Mmmmm tasty!
  13. Erik

    Erik Well-Known Member

    Yes, but sha256 is a more expensive hashing function and it would take longer to generate the tables than md5. :)

    Also, everyone should read this:
    Shadab likes this.
  14. Booth

    Booth Well-Known Member

    Salt gets a bad press, but you know where would we be without it ;)
    Dragonfly likes this.
  15. Shadab

    Shadab Well-Known Member

  16. Erik

    Erik Well-Known Member

    Same. :D
  17. Enigma

    Enigma Well-Known Member

    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.
  18. Erik

    Erik Well-Known Member

    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. ;)
  19. James

    James Well-Known Member

    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.
  20. Erik

    Erik Well-Known Member

    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. :)

Share This Page