5 ms·

> The leaked password hashes were salted bcrypt (FreeBSD's default libcrypt implementation). As bad as data leaks are, it's at least nice to see one of these d

by SCdF 12y ago

> The leaked password hashes were salted bcrypt (FreeBSD's default libcrypt implementation). As bad as data leaks are, it's at least nice to see one of these data leak stories where the passwords were actually stored correctly, instead of being MD5 / plaintext / base64.

baudehlo 12y ago
Be nice to know the number of rounds used though - the default of 10 in most implementations is starting to become not enough. Also bcrypt does not seem to be FreeBSD's default libcrypt implementation from the source code [1] - it appears to be DES (or SHA512 if DES isn't available). What makes HN think it's bcrypt? @kogir? [1] https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/crypt.c https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/...
- kogir 12y ago
  Thanks for pointing that out. You're correct (and I was wrong) - it's not the default, but we format our salts to request it. The docs are here: https://www.freebsd.org/cgi/man.cgi?query=crypt&apropos=0&sektion=3&manpath=FreeBSD+9.2-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=crypt&apropos=0&se... The code looks something like this: (withs (salt (+ "$2$10$" (rand-string 20)) ux (crypt pw salt)) <stuff>) "(rand-string 20)" provides 128 bits of randomness from /dev/urandom. I'll up the number of rounds and upgrade them in place as users log in. Thanks!
  - baby 12y ago
    I know it's compelling to answer users who ask for more transparency on security. But it's not the best thing to reveal implementation details after hashes were leaked.
    - tptacek 12y ago
      That's not how bcrypt works. If you have the hash, you know the number of rounds. Even if that weren't true --- and it very much is --- you'd still trivially be able to find that number given a single known password.
      - baby 12y ago
        > you'd still trivially be able to find that number given a single known password. I understand that it's because the salt is entirely appended in clear to the hash. Isn't it better to have a second static salt implemented in the code, in case only the database would be compromised?
        tptacek 12y ago
        I think those schemes are pretty silly, but as long as you're using a well-tested implementation of a real KDF and not some goofy scheme you hacked up yourself so you could add the second secret nonce, I don't care.
        baby 12y ago
        Alright, it's true that it feels silly to add negligible protections when your security here is reduced to the KDF and its implementation.
    - baudehlo 12y ago
      I honestly wouldn't ask if I thought that bcrypt could be cracked by knowing the number of iterations. Now there may be other bcrypt attacks out there, but none have been announced, and the usage of bcrypt was announced in the text of the post. Furthermore, if you have the hash, you have the number of rounds. I just have no desire to see if I can download the data (I don't trust random sites, and frankly I don't want the data). Security by obscurity is not worth the price you pay for it.
      - baby 12y ago
        > Security by obscurity is not worth the price you pay for it. That's why I was posting this. Many people think that because of the Kerckhoff principle you should always disclose everything. But obscurity is not always a bad thing and it can be part of the obfuscation here. Although here it was indeed a good thing since admins are gonna up the cost of their kdf following advice from the community.
lucb1e 12y ago
> one of these data leak stories where the passwords were actually stored correctly The reason we see so few hacks where passwords were stored properly might be because they do things properly, so odds are lower they get hacked in the first place. Just a thought.

by SCdF 12y ago

baudehlo 12y ago

Be nice to know the number of rounds used though - the default of 10 in most implementations is starting to become not enough. Also bcrypt does not seem to be FreeBSD's default libcrypt implementation from the source code [1] - it appears to be DES (or SHA512 if DES isn't available). What makes HN think it's bcrypt? @kogir? [1] https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/crypt.c https://github.com/freebsd/freebsd/blob/master/lib/libcrypt/...

kogir 12y ago
Thanks for pointing that out. You're correct (and I was wrong) - it's not the default, but we format our salts to request it. The docs are here: https://www.freebsd.org/cgi/man.cgi?query=crypt&apropos=0&sektion=3&manpath=FreeBSD+9.2-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=crypt&apropos=0&se... The code looks something like this: (withs (salt (+ "$2$10$" (rand-string 20)) ux (crypt pw salt)) <stuff>) "(rand-string 20)" provides 128 bits of randomness from /dev/urandom. I'll up the number of rounds and upgrade them in place as users log in. Thanks!
- baby 12y ago
  I know it's compelling to answer users who ask for more transparency on security. But it's not the best thing to reveal implementation details after hashes were leaked.
  - tptacek 12y ago
    That's not how bcrypt works. If you have the hash, you know the number of rounds. Even if that weren't true --- and it very much is --- you'd still trivially be able to find that number given a single known password.
    - baby 12y ago
      > you'd still trivially be able to find that number given a single known password. I understand that it's because the salt is entirely appended in clear to the hash. Isn't it better to have a second static salt implemented in the code, in case only the database would be compromised?
      - tptacek 12y ago
        I think those schemes are pretty silly, but as long as you're using a well-tested implementation of a real KDF and not some goofy scheme you hacked up yourself so you could add the second secret nonce, I don't care.
        baby 12y ago
        Alright, it's true that it feels silly to add negligible protections when your security here is reduced to the KDF and its implementation.
  - baudehlo 12y ago
    I honestly wouldn't ask if I thought that bcrypt could be cracked by knowing the number of iterations. Now there may be other bcrypt attacks out there, but none have been announced, and the usage of bcrypt was announced in the text of the post. Furthermore, if you have the hash, you have the number of rounds. I just have no desire to see if I can download the data (I don't trust random sites, and frankly I don't want the data). Security by obscurity is not worth the price you pay for it.
    - baby 12y ago
      > Security by obscurity is not worth the price you pay for it. That's why I was posting this. Many people think that because of the Kerckhoff principle you should always disclose everything. But obscurity is not always a bad thing and it can be part of the obfuscation here. Although here it was indeed a good thing since admins are gonna up the cost of their kdf following advice from the community.

lucb1e 12y ago

> one of these data leak stories where the passwords were actually stored correctly The reason we see so few hacks where passwords were stored properly might be because they do things properly, so odds are lower they get hacked in the first place. Just a thought.