3 ms·

How can a salt change on every encoding? There has to be a reference point, no?

by ck2 10y ago

tim333 10y ago
You can hash a fixed salt + password + some other user info like surname or email address. That way if you have the salt you can't just compute the hash of salt+"123456" to see who had that, you have to compute separately for each user.
- jfindley 10y ago
  What? No. Don't use a fixed salt. Each record should have a unique, random salt. You then store salt:hash(salt+password). There are numerous guides on how to do this properly, for example https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
  - DasIch 10y ago
    Though of coure you don't actually do that, you use something like bcrypt that does this for you.
    - jfindley 10y ago
      Yes absolutely this - I was just trying to explain how salts should implemented - in the real world always use something like bcrypt or scrypt that does all this for you.
      - tim333 10y ago
        OK, I think I got my terminology wrong. But my thinking was that as well as using bcrypt or whatever on the info in the database you can add some random value stored in code rather than in the database so if your database is compromised it's still a job for them to crack it. Not quite sure what you call that.
        heinrich5991 10y ago
        A pepper. https://en.wikipedia.org/wiki/Pepper_%28cryptography%29 https://en.wikipedia.org/wiki/Pepper_%28cryptography%29
  - Strom 10y ago
    Using a site-specific constant combined with the user's e-mail as the salt isn't too horrible. The owasp link you provided explains the two goals of using a salt: 1) Not being able to tell two passwords are identical based on the resulting hash. The e-mail is unique per user, so even if a bunch of users have "password" as their password, the hashes will all be different. Yes, if a user changes their password from "password" to "password" then the hash remains the same, but this is a very minor problem. 2) Prevent rainbow attacks. The constant part of the salt is enough to demand a site-specific rainbow table, and the e-mail takes this even further to a site + e-mail combo. Thus rainbow attacks would only have value in targeted attacks against a known site constant & e-mail combo. Once a good table is complete, it won't matter if the user changes their password. Using a unique random salt would solve these two issues, however they can also be solved by adding a simple timestamp of the password's initial hashing time to the salt.
    - sokoloff 10y ago
      site-specific content (or formulaic derivations based on other columns likely to be in the same DB dump) suffer from internal (or former internal) bad actor problems as well. Disgruntled (or just loose-lipped) ex-employees can leak the formula or constant and you have a false sense of security. (I'm not arguing it's "too horrible", but I am saying that it's worse than other schemes that aren't significantly more burdensome.)
    - Someone1234 10y ago
      A site specific constant is often called a "Pepper" as an aside. Just helps people google it if they want more information. Several implementations utilise a Salt + Papper (unique per user value and single per site value). A Pepper is particularly useful when it is NOT stored in the database (e.g. stored in an environmental variable or even code). That way if someone steals your database via SQL Injection or a database backup file, they'd have to break the Pepper to recover passwords. Peppers only make sense when they're almost "free" to implement. A slow hashing scheme is the most important thing, then unique salting, and finally a pepper last (since a pepper adds the least security wise).
paulmd 10y ago
You store the user's salt in a database column just like the hash. Optionally, when they change their password, you update the salt. If you accept the premise of a secure hash, then there's no predictable effect on the output when you change hash('mypass') to hash('onetimesalt' + 'mypass'). Knowing that the user's salt is 'onetimesalt' does not get the attacker any closer to figuring out which password was used with that salt. Therefore there is no harm to storing the salt unencrypted in the database. The advantage of doing this is that an attacker can't just make a single hashing run against common passwords using a single serverwide salt - they actually have to check the password list using every single user's salt. So if you have a million users (caveat: and your attacker is just scanning them all rather than going after a specific user), you've increased the complexity of an attack by a factor of a million.

How can a salt change on every encoding? There has to be a reference point, no?

by ck2 10y ago

How can a salt change on every encoding? There has to be a reference point, no?

You can hash a fixed salt + password + some other user info like surname or email address. That way if you have the salt you can't just compute the hash of salt+"123456" to see who had that, you have to compute separately for each user.

jfindley 10y ago
What? No. Don't use a fixed salt. Each record should have a unique, random salt. You then store salt:hash(salt+password). There are numerous guides on how to do this properly, for example https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
- DasIch 10y ago
  Though of coure you don't actually do that, you use something like bcrypt that does this for you.
  - jfindley 10y ago
    Yes absolutely this - I was just trying to explain how salts should implemented - in the real world always use something like bcrypt or scrypt that does all this for you.
    - tim333 10y ago
      OK, I think I got my terminology wrong. But my thinking was that as well as using bcrypt or whatever on the info in the database you can add some random value stored in code rather than in the database so if your database is compromised it's still a job for them to crack it. Not quite sure what you call that.
      - heinrich5991 10y ago
        A pepper. https://en.wikipedia.org/wiki/Pepper_%28cryptography%29 https://en.wikipedia.org/wiki/Pepper_%28cryptography%29
- Strom 10y ago
  Using a site-specific constant combined with the user's e-mail as the salt isn't too horrible. The owasp link you provided explains the two goals of using a salt: 1) Not being able to tell two passwords are identical based on the resulting hash. The e-mail is unique per user, so even if a bunch of users have "password" as their password, the hashes will all be different. Yes, if a user changes their password from "password" to "password" then the hash remains the same, but this is a very minor problem. 2) Prevent rainbow attacks. The constant part of the salt is enough to demand a site-specific rainbow table, and the e-mail takes this even further to a site + e-mail combo. Thus rainbow attacks would only have value in targeted attacks against a known site constant & e-mail combo. Once a good table is complete, it won't matter if the user changes their password. Using a unique random salt would solve these two issues, however they can also be solved by adding a simple timestamp of the password's initial hashing time to the salt.
  - sokoloff 10y ago
    site-specific content (or formulaic derivations based on other columns likely to be in the same DB dump) suffer from internal (or former internal) bad actor problems as well. Disgruntled (or just loose-lipped) ex-employees can leak the formula or constant and you have a false sense of security. (I'm not arguing it's "too horrible", but I am saying that it's worse than other schemes that aren't significantly more burdensome.)
  - Someone1234 10y ago
    A site specific constant is often called a "Pepper" as an aside. Just helps people google it if they want more information. Several implementations utilise a Salt + Papper (unique per user value and single per site value). A Pepper is particularly useful when it is NOT stored in the database (e.g. stored in an environmental variable or even code). That way if someone steals your database via SQL Injection or a database backup file, they'd have to break the Pepper to recover passwords. Peppers only make sense when they're almost "free" to implement. A slow hashing scheme is the most important thing, then unique salting, and finally a pepper last (since a pepper adds the least security wise).

paulmd 10y ago

You store the user's salt in a database column just like the hash. Optionally, when they change their password, you update the salt. If you accept the premise of a secure hash, then there's no predictable effect on the output when you change hash('mypass') to hash('onetimesalt' + 'mypass'). Knowing that the user's salt is 'onetimesalt' does not get the attacker any closer to figuring out which password was used with that salt. Therefore there is no harm to storing the salt unencrypted in the database. The advantage of doing this is that an attacker can't just make a single hashing run against common passwords using a single serverwide salt - they actually have to check the password list using every single user's salt. So if you have a million users (caveat: and your attacker is just scanning them all rather than going after a specific user), you've increased the complexity of an attack by a factor of a million.