5 ms·

I wonder how many password leaks would have been a "non-issue", if we had adopted the habit of adding also fixed salt to the passwords 15 years ago? The point

I wonder how many password leaks would have been a "non-issue", if we had adopted the habit of adding also fixed salt to the passwords 15 years ago? The point in using fixed salt would be that quite often the password leaks seem to be result of SQL injection attacks and therefore the attacker only gains access to the database. Not the source code. The password hashes from database would be much harder to crack if we were also using a fixed salt string that was only stored in code. Technically adding this kind of extra salt would be trivial on all platforms. I can't figure out any negative side effects related to it (Obviously it is not replacement to better password hashing schemes).

krainboltgreene 13y ago
If they have access to your database then they most likely can also get access to your source code.
- cschneid 13y ago
  That wouldn't be the case in many scenarios I can think of: 1. DB backup is compromised (from an offsite backup storage, think S3). 2. Developer laptop lost, with a copy of the database locally. (source code may be available, but the site-specific key probably wouldn't be. As that's a config var on the server). 3. SQLi that dumps hashes to the page. I'm a big fan of making the job harder for attackers. There are lots of attack vectors where a 'pepper' value would be useless. But not all of them. And it's nearly free to implement. Might as well.
lambda 13y ago
Your source code (or a running image of your program, that has the extra salt in memory) is rarely harder to get access to than your password database. Remember, all of your developers have access to it, and likely have it unencrypted on their machines, which may not be terribly secure. It would be a small enough extra value, and a large enough extra hassle (making it difficult to re-use the same encrypted password in other code, for instance use the same encrypted password for basic auth over HTTPS as you use for your webapp in a different area) that I don't think it's worth it. I also worry that promoting this practice would make some developers think that they didn't need a random, per-password salt as well. It's hard enough to convince developers about the value of using strong key derivation functions and a per-password salt, and if you added a global salt I'd worry that some would think that the per-password salt is not necessary. Then once the fixed salt were compromised, brute forcing individual passwords would become trivial. Also remember, the attacker could easily create an account with a known password, and they can get the normal salt from the password database. Now they just need to brute force the single "fixed salt", and you're back to where you started. No, it's much better to encourage people to just use strong password hash functions, like bcrypt or scrypt, with good, random, per password salts, than to try to apply a little security through obscurity by adding yet another salt that is likely easy to find.
- jpalomaki 13y ago
  Determining the fixed salt by using brute force is not feasible if some modern hash function is used. The fixed salt can be easily quite long, think about something like 200+ bits.
lawnchair_larry 13y ago
No, any scheme by which the salt is a secret is a failure.

krainboltgreene 13y ago

If they have access to your database then they most likely can also get access to your source code.

cschneid 13y ago
That wouldn't be the case in many scenarios I can think of: 1. DB backup is compromised (from an offsite backup storage, think S3). 2. Developer laptop lost, with a copy of the database locally. (source code may be available, but the site-specific key probably wouldn't be. As that's a config var on the server). 3. SQLi that dumps hashes to the page. I'm a big fan of making the job harder for attackers. There are lots of attack vectors where a 'pepper' value would be useless. But not all of them. And it's nearly free to implement. Might as well.

lambda 13y ago

Your source code (or a running image of your program, that has the extra salt in memory) is rarely harder to get access to than your password database. Remember, all of your developers have access to it, and likely have it unencrypted on their machines, which may not be terribly secure. It would be a small enough extra value, and a large enough extra hassle (making it difficult to re-use the same encrypted password in other code, for instance use the same encrypted password for basic auth over HTTPS as you use for your webapp in a different area) that I don't think it's worth it. I also worry that promoting this practice would make some developers think that they didn't need a random, per-password salt as well. It's hard enough to convince developers about the value of using strong key derivation functions and a per-password salt, and if you added a global salt I'd worry that some would think that the per-password salt is not necessary. Then once the fixed salt were compromised, brute forcing individual passwords would become trivial. Also remember, the attacker could easily create an account with a known password, and they can get the normal salt from the password database. Now they just need to brute force the single "fixed salt", and you're back to where you started. No, it's much better to encourage people to just use strong password hash functions, like bcrypt or scrypt, with good, random, per password salts, than to try to apply a little security through obscurity by adding yet another salt that is likely easy to find.

jpalomaki 13y ago
Determining the fixed salt by using brute force is not feasible if some modern hash function is used. The fixed salt can be easily quite long, think about something like 200+ bits.

lawnchair_larry 13y ago

No, any scheme by which the salt is a secret is a failure.