11 ms·

Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-salting-peppering-passwords http://stackoverflow.com/questions/16891729/best-pr

by stiff 12y ago

Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-salting-peppering-passwords http://stackoverflow.com/questions/16891729/best-practices-s...

atmosx 12y ago
That's a rather comprehensive answer from @ircmaxell over there, hm. Interesting, thanks for sharing.
baby 12y ago
so the downsides are "it's not maintanable" and "don't roll your own crypto". I think they are negligible compared to the upsides.
- mirashii 12y ago
  Not at all. "don't roll your own crypto" is a downside that can lead to things completely falling apart or weakening the system overall. The real downside is that there's a better, proven way to do the same effective thing, which is make a database-only compromise require additional work, without rolling your own crypto. It also supports doing things retroactively for real (not some of the hacks being discussed in this thread) and key-rotation. All the upsides, with none of the downsides.
- MarkyC4 12y ago
  The fact that the pepper can't be changed/rotated far outweighs any upsides
  - cpeterso 12y ago
    You can change your pepper by double-peppering your existing password database: scrypt(scrypt(scrypt(scrypt(password, salt), pepper2013), pepper2014), pepper2015) https://blog.filippo.io/salt-and-pepper/ https://blog.filippo.io/salt-and-pepper/
    - deleted 12y ago
      [deleted]
    - flurdy 12y ago
      Sounds like a maintenance nightmare. Need to ensure you keep your tongue straight when partitioning or restoring databases, migrating/splitting to new apps etc.
- urda 12y ago
  > "don't roll your own crypto". I think they are negligible Please do not ever consider "rolling your own crypto" a walk in the park. Unless you have a serious security background and some actual cryptography education and research never, never, NEVER do this. It is not negligible, and it is not safe.
- aturek 12y ago
  You consider "not maintainable" to be an acceptable downside to _anything_ you're doing with your software? What?
- MarkMc 12y ago
  I wouldn't say negligible, but rather not slam-dunk convincing
FiloSottile 12y ago
That sounds like fuzzy scare-mongering to me. 1) You should not invent your own algorithm. That's a given. That's why you use bcrypt/scrypt. 2) It's not abusing the algorithm, it's using a longer salt (in the concatenation case). 3) There's nothing wrong with nesting algorithms (just remember to use hex/base64 encodings, not binary). For example Facebook passes passwords through half a dozen algorithms. They call it the "onion". And it includes a pepper. 4) As for being effective, I think the SQL injection case speaks for itself. 5) As for rotation - just don't do it. You pepper gets compromised? Who cares, add a new one on top of the old one. Also, I'm confused at how the proposed alternative would be harder to get wrong: > Encrypt The Output Hash Prior To Storage
- danbruc 12y ago
  Your second point might be dangerous - your salt values are no longer random but heavily biased and knowing that all salt values share some common bits might provide a new attack vector.
  - antsar 12y ago
    Is this true? I would think that static bits are no more dangerous than not having the bits at all.
    - danbruc 12y ago
      Here is for example an attack recovering a 384 bit ECDSA key [1] by knowing the five least significant bits of the nonce (obtained by a side channel attack) for 4000 signatures. Now hashes and signatures are obviously very different things but I would not bet on the fact that a bias in the salt does not matter. [1] https://eprint.iacr.org/2013/346.pdf https://eprint.iacr.org/2013/346.pdf
      - antsar 12y ago
        Interesting. Thanks for the link!
      - 12y ago
scythe 12y ago
Why combine hashes? Just use XOR. If bcrypt can protect "not_my_password", it can certainly protect "KKQ{H]zTDWVSJVA", which is the former XOR'd by "%$". XOR doesn't decrease the keyspace (or change it in any interesting way), so any attack on XOR is an attack on bcrypt; XOR is fast enough to evade any sort of timing attacks, too.
- deleted 12y ago
  [deleted]
- mbrubeck 12y ago
  Careful. If an attacker is ever able to observe the output for a very short password - one byte, say - then only one byte of your secret salt is used, and the attacker could begin brute-forcing the secret salt starting with the first byte. XOR could also result in NULL bytes anywhere in the hash input, which could drastically weaken passwords,. For example, bcrypt ignores any password characters after the first NULL byte. This is especially bad if the attacker can supply their own passwords, doubly so if they can observe the output, since they can then easily brute-force individual bytes of the secret and use that knowledge to intentionally create NULL bytes in the hash input. > XOR doesn't decrease the keyspace (or change it in any interesting way), so any attack on XOR is an attack on bcrypt I wouldn't make any statement like this unless you've actually gone through the steps to prove it.
  - ionwake 12y ago
    >Careful. If an attacker is ever able to observe the output for a very short password - one byte, say - then only one byte of your secret salt is used, and the attacker could begin brute-forcing the secret salt starting with the first byte. Can you be kind enough to explain with a very simple example? I would appreciate understanding your point - Thank you
    - mbrubeck 12y ago
      Using the scheme above, a password of "a" would result in a hash H('a' ^ x) where x is the first byte of the secret salt. The attacker can simply test all possible values of x (there are only 256) to determine the value of that byte. Knowing the first byte, the attacker can then look at a two-byte password and repeat the process to brute-force the second byte. (It's also possible to brute-force more than one byte at a time; it would just take longer. For example if the shortest password the attacker can observe is 6 bytes then they would need to try 2^48 possibilities.)
JackC 12y ago
ircmaxell makes a good point in that comment -- not that the concept of a pepper doesn't work, but that a two-way encryption function is a better choice than a hash function for applying the pepper. Your pepper will be a long, random key that is known to your app server but not your database server. If you store passwords as: bcrypt(bcrypt(password, salt), pepper) then you spend a lot of cycles bcrypting your long, random key, which is pointless (it should already be long enough to be un-brute-forceable), and you lose the ability to rotate keys or ever stop using this scheme in the future. There's also (in theory) some risk that nested bcrypt() doesn't work predictably. If you store passwords instead as: encrypt(bcrypt(password, salt), pepper) then you can routinely rotate peppers through a simple one-time decrypt-and-encrypt step on your app server, instead of endlessly nesting peppers as suggested in the filippo.io blog post. The rest of it is more of a qualitative question -- what's the risk that someone gains access to your DB but not your app server, vs. the risk that in implementing the pepper, you somehow screw up and store something easily crackable?
- eridius 12y ago
  > what's the risk that someone gains access to your DB but not your app server, vs. the risk that in implementing the pepper, you somehow screw up and store something easily crackable? The question is irrelevant anyway, because if someone gets access to your app server, they get the secret in both cases (pepper and encryption). So the first risk there is present in both cases, which just makes this a static "what's the risk that you screw up in implementing the pepper?"
  - worklogin 12y ago
    The question is not irrelevant. It's blindingly obvious that salt+pepper protects against DB-only attacks. Injection that does a DB dump, or vulnerabilities in the DB server that don't exist in the app. So yes, S+P protection won't save you if the app server is completely compromised, but it does protect you in case DB only is. And the ability to S+P seems pretty simple to implement and document. Why is everyone panicking that it's hard to do?
    - 12y ago

by stiff 12y ago

Please do not do it: http://stackoverflow.com/questions/16891729/best-practices-salting-peppering-passwords http://stackoverflow.com/questions/16891729/best-practices-s...

atmosx 12y ago

That's a rather comprehensive answer from @ircmaxell over there, hm. Interesting, thanks for sharing.

baby 12y ago

so the downsides are "it's not maintanable" and "don't roll your own crypto". I think they are negligible compared to the upsides.

mirashii 12y ago
Not at all. "don't roll your own crypto" is a downside that can lead to things completely falling apart or weakening the system overall. The real downside is that there's a better, proven way to do the same effective thing, which is make a database-only compromise require additional work, without rolling your own crypto. It also supports doing things retroactively for real (not some of the hacks being discussed in this thread) and key-rotation. All the upsides, with none of the downsides.
MarkyC4 12y ago
The fact that the pepper can't be changed/rotated far outweighs any upsides
- cpeterso 12y ago
  You can change your pepper by double-peppering your existing password database: scrypt(scrypt(scrypt(scrypt(password, salt), pepper2013), pepper2014), pepper2015) https://blog.filippo.io/salt-and-pepper/ https://blog.filippo.io/salt-and-pepper/
  - deleted 12y ago
    [deleted]
  - flurdy 12y ago
    Sounds like a maintenance nightmare. Need to ensure you keep your tongue straight when partitioning or restoring databases, migrating/splitting to new apps etc.
urda 12y ago
> "don't roll your own crypto". I think they are negligible Please do not ever consider "rolling your own crypto" a walk in the park. Unless you have a serious security background and some actual cryptography education and research never, never, NEVER do this. It is not negligible, and it is not safe.
aturek 12y ago
You consider "not maintainable" to be an acceptable downside to _anything_ you're doing with your software? What?
MarkMc 12y ago
I wouldn't say negligible, but rather not slam-dunk convincing

FiloSottile 12y ago

That sounds like fuzzy scare-mongering to me. 1) You should not invent your own algorithm. That's a given. That's why you use bcrypt/scrypt. 2) It's not abusing the algorithm, it's using a longer salt (in the concatenation case). 3) There's nothing wrong with nesting algorithms (just remember to use hex/base64 encodings, not binary). For example Facebook passes passwords through half a dozen algorithms. They call it the "onion". And it includes a pepper. 4) As for being effective, I think the SQL injection case speaks for itself. 5) As for rotation - just don't do it. You pepper gets compromised? Who cares, add a new one on top of the old one. Also, I'm confused at how the proposed alternative would be harder to get wrong: > Encrypt The Output Hash Prior To Storage

danbruc 12y ago
Your second point might be dangerous - your salt values are no longer random but heavily biased and knowing that all salt values share some common bits might provide a new attack vector.
- antsar 12y ago
  Is this true? I would think that static bits are no more dangerous than not having the bits at all.
  - danbruc 12y ago
    Here is for example an attack recovering a 384 bit ECDSA key [1] by knowing the five least significant bits of the nonce (obtained by a side channel attack) for 4000 signatures. Now hashes and signatures are obviously very different things but I would not bet on the fact that a bias in the salt does not matter. [1] https://eprint.iacr.org/2013/346.pdf https://eprint.iacr.org/2013/346.pdf
    - antsar 12y ago
      Interesting. Thanks for the link!
    - 12y ago

scythe 12y ago

Why combine hashes? Just use XOR. If bcrypt can protect "not_my_password", it can certainly protect "KKQ{H]zTDWVSJVA", which is the former XOR'd by "%$". XOR doesn't decrease the keyspace (or change it in any interesting way), so any attack on XOR is an attack on bcrypt; XOR is fast enough to evade any sort of timing attacks, too.

deleted 12y ago
[deleted]
mbrubeck 12y ago
Careful. If an attacker is ever able to observe the output for a very short password - one byte, say - then only one byte of your secret salt is used, and the attacker could begin brute-forcing the secret salt starting with the first byte. XOR could also result in NULL bytes anywhere in the hash input, which could drastically weaken passwords,. For example, bcrypt ignores any password characters after the first NULL byte. This is especially bad if the attacker can supply their own passwords, doubly so if they can observe the output, since they can then easily brute-force individual bytes of the secret and use that knowledge to intentionally create NULL bytes in the hash input. > XOR doesn't decrease the keyspace (or change it in any interesting way), so any attack on XOR is an attack on bcrypt I wouldn't make any statement like this unless you've actually gone through the steps to prove it.
- ionwake 12y ago
  >Careful. If an attacker is ever able to observe the output for a very short password - one byte, say - then only one byte of your secret salt is used, and the attacker could begin brute-forcing the secret salt starting with the first byte. Can you be kind enough to explain with a very simple example? I would appreciate understanding your point - Thank you
  - mbrubeck 12y ago
    Using the scheme above, a password of "a" would result in a hash H('a' ^ x) where x is the first byte of the secret salt. The attacker can simply test all possible values of x (there are only 256) to determine the value of that byte. Knowing the first byte, the attacker can then look at a two-byte password and repeat the process to brute-force the second byte. (It's also possible to brute-force more than one byte at a time; it would just take longer. For example if the shortest password the attacker can observe is 6 bytes then they would need to try 2^48 possibilities.)

JackC 12y ago

ircmaxell makes a good point in that comment -- not that the concept of a pepper doesn't work, but that a two-way encryption function is a better choice than a hash function for applying the pepper. Your pepper will be a long, random key that is known to your app server but not your database server. If you store passwords as: bcrypt(bcrypt(password, salt), pepper) then you spend a lot of cycles bcrypting your long, random key, which is pointless (it should already be long enough to be un-brute-forceable), and you lose the ability to rotate keys or ever stop using this scheme in the future. There's also (in theory) some risk that nested bcrypt() doesn't work predictably. If you store passwords instead as: encrypt(bcrypt(password, salt), pepper) then you can routinely rotate peppers through a simple one-time decrypt-and-encrypt step on your app server, instead of endlessly nesting peppers as suggested in the filippo.io blog post. The rest of it is more of a qualitative question -- what's the risk that someone gains access to your DB but not your app server, vs. the risk that in implementing the pepper, you somehow screw up and store something easily crackable?

eridius 12y ago
> what's the risk that someone gains access to your DB but not your app server, vs. the risk that in implementing the pepper, you somehow screw up and store something easily crackable? The question is irrelevant anyway, because if someone gets access to your app server, they get the secret in both cases (pepper and encryption). So the first risk there is present in both cases, which just makes this a static "what's the risk that you screw up in implementing the pepper?"
- worklogin 12y ago
  The question is not irrelevant. It's blindingly obvious that salt+pepper protects against DB-only attacks. Injection that does a DB dump, or vulnerabilities in the DB server that don't exist in the app. So yes, S+P protection won't save you if the app server is completely compromised, but it does protect you in case DB only is. And the ability to S+P seems pretty simple to implement and document. Why is everyone panicking that it's hard to do?
  - 12y ago