5 ms·

In incident response you assume the worst, but in system design you try to minimize impact of common attacks like SQL injection. There's nothing wrong with nes

In incident response you assume the worst, but in system design you try to minimize impact of common attacks like SQL injection. There's nothing wrong with nesting algorithms (see the Facebook hash onion), so you can use the following scheme: bcrypt(bcrypt(password, salt), pepper) And do a pass on all your database entries like bcrypt(old_hash, pepper)

randunel 12y ago
In your website's example, you have bcrypt(password, salt+pepper) Observe the difference between that and the rehash you just posted bcrypt(bcrypt(password, salt), pepper)
- deleted 12y ago
  [deleted]
- mbrubeck 12y ago
  > bcrypt(password, salt+pepper) I hope it's obvious that no one should never do this, since the output would contain the "salt+pepper" bits in cleartext alongside the hash, defeating the entire point of the "pepper": https://www.usenix.org/legacy/event/usenix99/provos/provos_html/node5.html https://www.usenix.org/legacy/event/usenix99/provos/provos_h... In fact, this is a perfect illustration of why it's bad to put secret bits into a crypto function in a place that's not designed to take secret bits. Bcrypt does not treat the salt parameter as a cryptographic secret, and other algorithms might not either. And they might leak it in more subtle ways.
  - rmrfrmrf 12y ago
    One would think it's obvious, yet this is what the person in the linked article suggests doing :/
minitech 12y ago
> There's nothing wrong with nesting algorithms This is really vague. What kind of algorithm? With itself, or just anything inside anything else? Passing the raw output of any common cryptographic hash (SHA-x) to bcrypt, for example, completely destroys its security, as bcrypt input is null-terminated. (What happens when you nest DES in A*, anyway?)
- Dylan16807 12y ago
  Obviously you have to use type safety. You can't cast a binary string to a null-terminated string, you have to convert. That's a problem unrelated to hashing. I would avoid using any particular symmetric algorithm twice. Otherwise if you have an example of algorithm chaining that can weaken security beyond the weakest link, I would love to see it. (Not that I think nesting is a great idea.)
  - minitech 12y ago
    > That's a problem unrelated to hashing. It (poor implementation) is definitely related to implementing pepper on top of a secure password hash, though, which everybody is already doing differently. > I would avoid using any particular symmetric algorithm twice. Otherwise if you have an example of algorithm chaining that can weaken security beyond the weakest link, I would love to see it. (Not that I think nesting is a great idea.) “algorithm” is, again, really vague. (So is “nesting”.) But for something contrived and not snarky, here: h = sha512_hex(password) sha512_hex(bcrypt(h, gen_salt()) + bcrypt(h, gen_salt()) + bcrypt(h, gen_salt()) + bcrypt(h, gen_salt())) The weakest link here is 374 bits (4 bcrypts), but the output is 288.
    - Dylan16807 12y ago
      Oh sorry I missed this post for a while. >“algorithm” is, again, really vague Something that you can use to hash passwords. What you gave works if you assume gen_salt is seeded per user. >The weakest link here is 374 bits (4 bcrypts), but the output is 288. I'm afraid I don't follow. Your bit numbers confuse me, and I don't see how this results in an algorithm that is weaker than either sha512 or bcrypt.
      - minitech 12y ago
        > I'm afraid I don't follow. Your bit numbers confuse me They’re bits of entropy (not counting the password itself) (I think). SHA-512(M): 512 bits; SHA-512(SHA-256(M)): 256 bits, for example. > I don't see how this results in an algorithm that is weaker than either sha512 or bcrypt. That’s my point. It’s not easy to get this kind of thing right, so just don’t bother with pepper.

randunel 12y ago

In your website's example, you have bcrypt(password, salt+pepper) Observe the difference between that and the rehash you just posted bcrypt(bcrypt(password, salt), pepper)

deleted 12y ago
[deleted]
mbrubeck 12y ago
> bcrypt(password, salt+pepper) I hope it's obvious that no one should never do this, since the output would contain the "salt+pepper" bits in cleartext alongside the hash, defeating the entire point of the "pepper": https://www.usenix.org/legacy/event/usenix99/provos/provos_html/node5.html https://www.usenix.org/legacy/event/usenix99/provos/provos_h... In fact, this is a perfect illustration of why it's bad to put secret bits into a crypto function in a place that's not designed to take secret bits. Bcrypt does not treat the salt parameter as a cryptographic secret, and other algorithms might not either. And they might leak it in more subtle ways.
- rmrfrmrf 12y ago
  One would think it's obvious, yet this is what the person in the linked article suggests doing :/

minitech 12y ago

> There's nothing wrong with nesting algorithms This is really vague. What kind of algorithm? With itself, or just anything inside anything else? Passing the raw output of any common cryptographic hash (SHA-x) to bcrypt, for example, completely destroys its security, as bcrypt input is null-terminated. (What happens when you nest DES in A*, anyway?)

Dylan16807 12y ago
Obviously you have to use type safety. You can't cast a binary string to a null-terminated string, you have to convert. That's a problem unrelated to hashing. I would avoid using any particular symmetric algorithm twice. Otherwise if you have an example of algorithm chaining that can weaken security beyond the weakest link, I would love to see it. (Not that I think nesting is a great idea.)
- minitech 12y ago
  > That's a problem unrelated to hashing. It (poor implementation) is definitely related to implementing pepper on top of a secure password hash, though, which everybody is already doing differently. > I would avoid using any particular symmetric algorithm twice. Otherwise if you have an example of algorithm chaining that can weaken security beyond the weakest link, I would love to see it. (Not that I think nesting is a great idea.) “algorithm” is, again, really vague. (So is “nesting”.) But for something contrived and not snarky, here: h = sha512_hex(password) sha512_hex(bcrypt(h, gen_salt()) + bcrypt(h, gen_salt()) + bcrypt(h, gen_salt()) + bcrypt(h, gen_salt())) The weakest link here is 374 bits (4 bcrypts), but the output is 288.
  - Dylan16807 12y ago
    Oh sorry I missed this post for a while. >“algorithm” is, again, really vague Something that you can use to hash passwords. What you gave works if you assume gen_salt is seeded per user. >The weakest link here is 374 bits (4 bcrypts), but the output is 288. I'm afraid I don't follow. Your bit numbers confuse me, and I don't see how this results in an algorithm that is weaker than either sha512 or bcrypt.
    - minitech 12y ago
      > I'm afraid I don't follow. Your bit numbers confuse me They’re bits of entropy (not counting the password itself) (I think). SHA-512(M): 512 bits; SHA-512(SHA-256(M)): 256 bits, for example. > I don't see how this results in an algorithm that is weaker than either sha512 or bcrypt. That’s my point. It’s not easy to get this kind of thing right, so just don’t bother with pepper.