5 ms·

I think it's best to allow longer passwords for those who use long phrases. It's easier to remember the full phrase than a truncated version. You could show a w

I think it's best to allow longer passwords for those who use long phrases. It's easier to remember the full phrase than a truncated version. You could show a warning that the extra chars beyond 50-55 will be ignored.

kijin 10y ago
Or you could SHA256 the original password and feed the hash to bcrypt. Remember to use the 64-byte hexadecimal hash, not the 32-byte binary because bcrypt chokes on null bytes. Everyone's been saying "just use bcrypt", but bcrypt has too many gotchas to be the default choice. We really need to work on getting scrypt and argon2 into the most popular programming languages and frameworks a.s.a.p.
- bschwindHN 10y ago
  Is "just use scrypt" an acceptable answer then? I'm not a security expert and I don't know the advantages of one over the other.
  - amenghra 10y ago
    Yes, scrypt is a perfectly fine password hash. If you are currently using something else (say salted md5 or even just plain md5), you can migrate your passwords to scrpyt(current_hash()) without having to change everyone's password and/or wait for everyone to log in. See also this comment thread: https://news.ycombinator.com/item?id=12549110 https://news.ycombinator.com/item?id=12549110
    - aaronbasssett 10y ago
      Don't do that. You've essentially just turned the old hashes into plain-text passwords, and how sure are you that those hashes don't exist in backups anywhere?
      - StavrosK 10y ago
        Not if you mark the converted versions and try scrypt(oldhash()) on users authenticating with them.
      - fractal618 10y ago
        Woah! Very good point!
      - rietta 10y ago
        No, not exactly. An adversary who has the old hash, but not the plaintext that it represents cannot login because scrypt(H(H(value))) != scrypt(H(value)). This is not considering the offline crackability of a compromised hash. But there are legitimate situations where upgrading the password backing to a modern slow hash is preferable to continuing to use the old hash or worse storing the old hash as a field for a long time so that when a breach happens both the new and old hashes are available. There are user experience battles when talking about forcing a million users to change their passwords in a real system. Hashing the hash may be vastly preferable to management nixing the security upgrade. A password updating schema that changes the hash as users login and eventually locking the accounts of users who have not logged in for an extended period of time can accomplish rolling the hashes without having to tell users to change their passwords.
  - kijin 10y ago
    scrypt is okay if you use it correctly. It's too easy to use it incorrectly, though, because scrypt is a low-level algorithm that wasn't specifically designed for password storage. [1] http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp... In order to be able to tell people to "just use scrypt", we would need to have a sort of standard wrapper that uses the correct parameters by default and produces identical results in every common programming language.
- blowski 10y ago
  > Everyone's been saying "just use bcrypt", but bcrypt has too many gotchas to be the default choice This has got to be the underlying problem of modern security. By the time a best practice is well known, it's no longer best practice.
  - dajohnson89 10y ago
    I think that's a good observation. The implication seems to be that we're not iterating fast enough, or not sufficiently fast in implementing changes/improvements. On the flipside, isn't there a risk of moving too quickly? There's a certain culture of caution because there's something to be said for "if it aint broke, don't fix it." and even if something is broke, how certain are we that cool new encryption algorithm is better or safer?
  - kaeluka 10y ago
    Like nutrition!
- paulmd 10y ago
  You would probably want to use PBKDF2 as a key-stretching function rather than just naive SHA256. Otherwise you're clipping your bcrypt input from "56 arbitrary bytes" down to "56 hexadecimal characters". I haven't looked deeply at this, but using "key stretching" that clips your output characters to such a small space smells very suspect to me. Remember: there is only 32 bytes of actual output there, regardless of whether you represent it as hex or binary. And since bcrypt can't take more than 56 bytes of input, you are clipping that down to the equivalent of 23 bytes.
zeveb 10y ago
> You could show a warning that the extra chars beyond 50-55 will be ignored. Or you could use a better KDF, e.g. scrypt (even PBKDF2 is better on this metric). Artificial password-length restrictions are symptomatic of poor design.

kijin 10y ago

Or you could SHA256 the original password and feed the hash to bcrypt. Remember to use the 64-byte hexadecimal hash, not the 32-byte binary because bcrypt chokes on null bytes. Everyone's been saying "just use bcrypt", but bcrypt has too many gotchas to be the default choice. We really need to work on getting scrypt and argon2 into the most popular programming languages and frameworks a.s.a.p.

bschwindHN 10y ago
Is "just use scrypt" an acceptable answer then? I'm not a security expert and I don't know the advantages of one over the other.
- amenghra 10y ago
  Yes, scrypt is a perfectly fine password hash. If you are currently using something else (say salted md5 or even just plain md5), you can migrate your passwords to scrpyt(current_hash()) without having to change everyone's password and/or wait for everyone to log in. See also this comment thread: https://news.ycombinator.com/item?id=12549110 https://news.ycombinator.com/item?id=12549110
  - aaronbasssett 10y ago
    Don't do that. You've essentially just turned the old hashes into plain-text passwords, and how sure are you that those hashes don't exist in backups anywhere?
    - StavrosK 10y ago
      Not if you mark the converted versions and try scrypt(oldhash()) on users authenticating with them.
    - fractal618 10y ago
      Woah! Very good point!
    - rietta 10y ago
      No, not exactly. An adversary who has the old hash, but not the plaintext that it represents cannot login because scrypt(H(H(value))) != scrypt(H(value)). This is not considering the offline crackability of a compromised hash. But there are legitimate situations where upgrading the password backing to a modern slow hash is preferable to continuing to use the old hash or worse storing the old hash as a field for a long time so that when a breach happens both the new and old hashes are available. There are user experience battles when talking about forcing a million users to change their passwords in a real system. Hashing the hash may be vastly preferable to management nixing the security upgrade. A password updating schema that changes the hash as users login and eventually locking the accounts of users who have not logged in for an extended period of time can accomplish rolling the hashes without having to tell users to change their passwords.
- kijin 10y ago
  scrypt is okay if you use it correctly. It's too easy to use it incorrectly, though, because scrypt is a low-level algorithm that wasn't specifically designed for password storage. [1] http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp... In order to be able to tell people to "just use scrypt", we would need to have a sort of standard wrapper that uses the correct parameters by default and produces identical results in every common programming language.
blowski 10y ago
> Everyone's been saying "just use bcrypt", but bcrypt has too many gotchas to be the default choice This has got to be the underlying problem of modern security. By the time a best practice is well known, it's no longer best practice.
- dajohnson89 10y ago
  I think that's a good observation. The implication seems to be that we're not iterating fast enough, or not sufficiently fast in implementing changes/improvements. On the flipside, isn't there a risk of moving too quickly? There's a certain culture of caution because there's something to be said for "if it aint broke, don't fix it." and even if something is broke, how certain are we that cool new encryption algorithm is better or safer?
- kaeluka 10y ago
  Like nutrition!
paulmd 10y ago
You would probably want to use PBKDF2 as a key-stretching function rather than just naive SHA256. Otherwise you're clipping your bcrypt input from "56 arbitrary bytes" down to "56 hexadecimal characters". I haven't looked deeply at this, but using "key stretching" that clips your output characters to such a small space smells very suspect to me. Remember: there is only 32 bytes of actual output there, regardless of whether you represent it as hex or binary. And since bcrypt can't take more than 56 bytes of input, you are clipping that down to the equivalent of 23 bytes.

zeveb 10y ago

> You could show a warning that the extra chars beyond 50-55 will be ignored. Or you could use a better KDF, e.g. scrypt (even PBKDF2 is better on this metric). Artificial password-length restrictions are symptomatic of poor design.