7 ms·

What's the best way to deal with this problem, and what's the correct way to deal with this problem?

akerl_ 11y ago
The input the user puts into the password prompt should by taken exactly as is, pushed into bcrypt/scrypt/etc, then stored as the user's password hash. I'm not entirely opposed to requiring a minimum length, but imposing max lengths / character class rules / etc ends up hurting people who want to pick strong passwords more than it helps people who would pick weak ones (enforcing character classes just gets us lots of password1A! and similar)
- cookiecaper 11y ago
  I agree that the only real restriction that makes sense is a minimum character count. The others just tend to get in the way. I haven't seen anyone implement it in the wild, but it'd also be cool if there was a wordlist of the 25 most common passwords that the site matched against and refused to accept. I think those two policies, minimum length and no super common passwords, would do a lot to minimize the effectiveness of dictionary attacks.
  - mbreese 11y ago
    I personally like the Stanford policy[1]. It basically boils down to: the longer the password, the fewer restrictions. Each password needs to be at least 8 characters, but if you only have 8 characters, you might need uppercase, lowercase, a symbol and a digit. If you have 12 characters, you only need upper/lower/digit. Once you hit 20 characters, you can have whatever you want. I think that this is a good balance between security for short passwords, while still allowing ridiculously long ones (pass-phrases). [1] http://arstechnica.com/security/2014/04/stanfords-password-policy-shuns-one-size-fits-all-security/ http://arstechnica.com/security/2014/04/stanfords-password-p...
    - warfangle 11y ago
      Almost like you're validating on entropy and not specific rules..........
    - Dylan16807 11y ago
      The concept is nice, but their numbers are horribly, unforgivably wrong. 8 random upper/lower/digit/symbol characters are equal to 9 random mixed-case letters. Not 16. Their cutoffs for different mixes are 8, 12, 16, 20. Realistic cutoffs would look more like 10, 11, 11, 14. Even worse, they encourage counting the individual letters in words. Never do that. Random words are only as good as two random characters.
    - technion 11y ago
      $ dd if=/dev/urandom bs=32 count=1 | xxd -p That nearly every site on the Internet will refer to that output as "not strong enough" and instead suggest P@ssword1 as a better alternative definitely speaks to the issue.
  - rmc 11y ago
    > I haven't seen anyone implement it in the wild, but it'd also be cool if there was a wordlist of the 25 most common passwords that the site matched against and refused to accept. I have implemented that on a site. It wouldn't accept the top 10,000 most common passwords. (or was it 1k). Otherwise ~1% of your users will pick "password" as a password.
  - tragic 11y ago
    > I haven't seen anyone implement it in the wild, but it'd also be cool if there was a wordlist of the 25 most common passwords that the site matched against and refused to accept It's now in django[0]. And it's a hoot to read... [0] https://github.com/django/django/blob/master/django/contrib/auth/common-passwords.txt.gz https://github.com/django/django/blob/master/django/contrib/...
- ars 11y ago
  > The input the user puts into the password prompt should by taken exactly as is I would however suggest trimming trailing spaces. Also, for a nicer user experience try the password twice: As is, and with case reversed. This lets people login even with capslock on and has little impact on security (i.e. don't be case insensitive! just case reversed.)
  - tempestn 11y ago
    I see the reasoning behind trimming trailing spaces, but it could cause at least as many problems as it solves. Plenty of people use automatically generated passwords, and while hopefully most auto-generators don't include spaces, I expect some might. Better might be to warn the user if their password has a trailing space.
    - nothrabannosir 11y ago
      Is there any password generator in this reality which does that? Serious question. More than zero?
      - tempestn 11y ago
        Probably not a serious one, but a lot of people write their own little scripts and utilities to do this. So definitely more than zero. Perhaps not a significant number, but I'd still be concerned about changing a user's entered password without letting them know. relearn's solution is a good one though.
    - deleted 11y ago
      [deleted]
    - relearn 11y ago
      Could you not trim spaces upon attempted login as well to make this a non-issue? I do like the idea of warning the user upon creation.
      - tempestn 11y ago
- Freaky 11y ago
  > imposing max lengths .. ends up hurting people In that case you'll want to pre-hash your BCrypt-encoded passwords, otherwise you'll be imposing a silent 72 character limit. Remember to encode the hashes, since BCrypt also silently truncates after NULL bytes.
  - zeveb 11y ago
    > In that case you'll want to pre-hash your BCrypt-encoded passwords, otherwise you'll be imposing a silent 72 character limit. Or just use PBKDF2 or scrypt, neither of which imposes an artificial length limitation on passwords. Not that it really matters, since a 72-character password will have hundreds of bits of entropy as long as the alphabet is more than two characters; it's overkill.
    - Freaky 11y ago
      I wouldn't expect a passphrase that long to be particularly entropy-dense - quite the opposite really. Some people do things like pick phrases from Hamlet and stuff some numbers on the end, so truncating them would seriously compromise their expected strength. Or XKCD style passphrases. Using the Oxford 3000 dictionary gets you about 1 bit of entropy per character. If I have my password manager generate 128 bit passphrases using them for ease of use in the real world, plain bcrypt will quietly reduce their strength by about 17 orders of magnitude. If nothing else that's obnoxious. And that's ignoring the soft 55 byte limit both the bcrypt spec and the original scrypt paper mention. If we're looking at less than one bit per byte that's starting to get into worryingly weak territory. Either way, it's all solved by stuffing a (e.g.) base64 SHA384 in there. Bam, every input bit equally effects the output hash regardless of length and position, and the entire thing even becomes NULL byte safe.
- rmc 11y ago
  The problem is that lots of people will pick "password" as a password. I think it's the responsibility of websites to prevent that from happening.
  - infogulch 11y ago
    That's why you download a list of the 10k most common passwords and not let a user choose one from the list. Way better than some arbitrary character class rules that are easily worked around by appending "1A!" to the end of an awful password like GP mentioned.
bjt 11y ago
Use https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn.
lmm 11y ago
The correct way is not to use passwords. Use X.509 client certificates, and let the user secure theirs whatever way makes sense to them (whether that's a password, a smartcard, both, or something else). Unfortunately the browser UX for them is terrible.

The input the user puts into the password prompt should by taken exactly as is, pushed into bcrypt/scrypt/etc, then stored as the user's password hash. I'm not entirely opposed to requiring a minimum length, but imposing max lengths / character class rules / etc ends up hurting people who want to pick strong passwords more than it helps people who would pick weak ones (enforcing character classes just gets us lots of password1A! and similar)

cookiecaper 11y ago
I agree that the only real restriction that makes sense is a minimum character count. The others just tend to get in the way. I haven't seen anyone implement it in the wild, but it'd also be cool if there was a wordlist of the 25 most common passwords that the site matched against and refused to accept. I think those two policies, minimum length and no super common passwords, would do a lot to minimize the effectiveness of dictionary attacks.
- mbreese 11y ago
  I personally like the Stanford policy[1]. It basically boils down to: the longer the password, the fewer restrictions. Each password needs to be at least 8 characters, but if you only have 8 characters, you might need uppercase, lowercase, a symbol and a digit. If you have 12 characters, you only need upper/lower/digit. Once you hit 20 characters, you can have whatever you want. I think that this is a good balance between security for short passwords, while still allowing ridiculously long ones (pass-phrases). [1] http://arstechnica.com/security/2014/04/stanfords-password-policy-shuns-one-size-fits-all-security/ http://arstechnica.com/security/2014/04/stanfords-password-p...
  - warfangle 11y ago
    Almost like you're validating on entropy and not specific rules..........
  - Dylan16807 11y ago
    The concept is nice, but their numbers are horribly, unforgivably wrong. 8 random upper/lower/digit/symbol characters are equal to 9 random mixed-case letters. Not 16. Their cutoffs for different mixes are 8, 12, 16, 20. Realistic cutoffs would look more like 10, 11, 11, 14. Even worse, they encourage counting the individual letters in words. Never do that. Random words are only as good as two random characters.
  - technion 11y ago
    $ dd if=/dev/urandom bs=32 count=1 | xxd -p That nearly every site on the Internet will refer to that output as "not strong enough" and instead suggest P@ssword1 as a better alternative definitely speaks to the issue.
- rmc 11y ago
  > I haven't seen anyone implement it in the wild, but it'd also be cool if there was a wordlist of the 25 most common passwords that the site matched against and refused to accept. I have implemented that on a site. It wouldn't accept the top 10,000 most common passwords. (or was it 1k). Otherwise ~1% of your users will pick "password" as a password.
- tragic 11y ago
  > I haven't seen anyone implement it in the wild, but it'd also be cool if there was a wordlist of the 25 most common passwords that the site matched against and refused to accept It's now in django[0]. And it's a hoot to read... [0] https://github.com/django/django/blob/master/django/contrib/auth/common-passwords.txt.gz https://github.com/django/django/blob/master/django/contrib/...
ars 11y ago
> The input the user puts into the password prompt should by taken exactly as is I would however suggest trimming trailing spaces. Also, for a nicer user experience try the password twice: As is, and with case reversed. This lets people login even with capslock on and has little impact on security (i.e. don't be case insensitive! just case reversed.)
- tempestn 11y ago
  I see the reasoning behind trimming trailing spaces, but it could cause at least as many problems as it solves. Plenty of people use automatically generated passwords, and while hopefully most auto-generators don't include spaces, I expect some might. Better might be to warn the user if their password has a trailing space.
  - nothrabannosir 11y ago
    Is there any password generator in this reality which does that? Serious question. More than zero?
    - tempestn 11y ago
      Probably not a serious one, but a lot of people write their own little scripts and utilities to do this. So definitely more than zero. Perhaps not a significant number, but I'd still be concerned about changing a user's entered password without letting them know. relearn's solution is a good one though.
  - deleted 11y ago
    [deleted]
  - relearn 11y ago
    Could you not trim spaces upon attempted login as well to make this a non-issue? I do like the idea of warning the user upon creation.
    - tempestn 11y ago
Freaky 11y ago
> imposing max lengths .. ends up hurting people In that case you'll want to pre-hash your BCrypt-encoded passwords, otherwise you'll be imposing a silent 72 character limit. Remember to encode the hashes, since BCrypt also silently truncates after NULL bytes.
- zeveb 11y ago
  > In that case you'll want to pre-hash your BCrypt-encoded passwords, otherwise you'll be imposing a silent 72 character limit. Or just use PBKDF2 or scrypt, neither of which imposes an artificial length limitation on passwords. Not that it really matters, since a 72-character password will have hundreds of bits of entropy as long as the alphabet is more than two characters; it's overkill.
  - Freaky 11y ago
    I wouldn't expect a passphrase that long to be particularly entropy-dense - quite the opposite really. Some people do things like pick phrases from Hamlet and stuff some numbers on the end, so truncating them would seriously compromise their expected strength. Or XKCD style passphrases. Using the Oxford 3000 dictionary gets you about 1 bit of entropy per character. If I have my password manager generate 128 bit passphrases using them for ease of use in the real world, plain bcrypt will quietly reduce their strength by about 17 orders of magnitude. If nothing else that's obnoxious. And that's ignoring the soft 55 byte limit both the bcrypt spec and the original scrypt paper mention. If we're looking at less than one bit per byte that's starting to get into worryingly weak territory. Either way, it's all solved by stuffing a (e.g.) base64 SHA384 in there. Bam, every input bit equally effects the output hash regardless of length and position, and the entire thing even becomes NULL byte safe.
rmc 11y ago
The problem is that lots of people will pick "password" as a password. I think it's the responsibility of websites to prevent that from happening.
- infogulch 11y ago
  That's why you download a list of the 10k most common passwords and not let a user choose one from the list. Way better than some arbitrary character class rules that are easily worked around by appending "1A!" to the end of an awful password like GP mentioned.

bjt 11y ago

Use https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn.

lmm 11y ago

The correct way is not to use passwords. Use X.509 client certificates, and let the user secure theirs whatever way makes sense to them (whether that's a password, a smartcard, both, or something else). Unfortunately the browser UX for them is terrible.