4 ms·

Such long passwords are silly, they will be effectively truncated by the key length of the underlying cryptography.

sweetjuly 1y ago
Passwords are (or, rather, SHOULD be) cryptographically hashed rather than encrypted. It's possible to compute a hash over data which is longer than the hash input block size by feeding precious hashes and the next input block back in to progressively build up a hash of the entire data.
- xx_ns 1y ago
  bcrypt, one of the more popular password hashing algorithms out there, allows the password to be up to 72 characters in length. Any characters beyond that 72 limit are ignored and the password is silently truncated (!!!). It's actually a good method of testing whether a site uses bcrypt or not. If you set a password longer than 72 characters, but can sign in using just the 72 characters of your password, they're in all likelihood using bcrypt.
  - deleted 1y ago
    [deleted]
  - integralid 1y ago
    Yeah, that's why bcrypt is broken and shouldn't be used today. It had a good run, but nowadays we have better options like scrypt or argon2.
    - daneel_w 1y ago
      It's not broken. It's just potentially less helpful when it comes to protecting poor guessable passwords. bcrypt isn't the problem, weak password policies/habits are. Like bcrypt, argon2 is just a bandaid, though a tiny bit thicker. It won't save you from absurdly short passwords or silly "correct horse battery staple" advice, and it's no better than bcrypt at protecting proper unguessable passwords. Also, only developers who have no idea know what they're doing will feed plain-text passwords to their hasher. You should be peppering and pre-digesting the passwords, and at that point bcrypt's 72 character input limit doesn't matter.
      - kbolino 1y ago
        Bcrypt alone is unfit for purpose. Argon2 does not need its input to be predigested. It's easy for somebody who knows this to fix bcrypt, but silently truncating the input was an unforced error. The fact that it looks like and was often sold as the right tool for the job but isn't has led to real-world vulnerabilities. It's a classic example of crypto people not anticipating how things actually get used. (Otherwise, though, I agree)
        daneel_w 1y ago
        Peppering is for protecting self-contained password hashes in case they leak. It's a secondary salt meant to be situated 1) external to the hash, and 2) external to the storage component the hashes reside in (i.e. not in the database you store accounts and hashes in). The method has nothing to do with trying to fix anything with bcrypt. You should be peppering your input even if you use Argon2.
        kbolino 1y ago
        Right, but peppering was not part of my comment. You can't always pepper, and there are different ways to do it. It's (mostly) orthogonal to the matter. You do not have to do any transformations on the input when using Argon2, while you must transform the input before using bcrypt. This was, again, an unnecessary and dangerous (careless) design choice.
        daneel_w 1y ago
        I don't understand your responses here. Clearly you are not familiar with what problem peppering solves, or why it's a recommended practice, no matter what self-contained password hashing you use. bcrypt, scrypt, Argon2; they are all subject to the same recommendation because they all store their salt together with the digest. You can always use a pepper, you should always use a pepper, and there's only one appropriate way to do it.
        1y ago
- whyever 1y ago
  Yes, in this case it would be easier to brute-force the key instead of the password, so the additional characters don't really help.
  - Hackbraten 1y ago
    Brute-forcing the underlying key doesn’t help if you’re trying to mount a credential stuffing attack. Brute-forcing the password does.
FabHK 1y ago
Agreed. But since every character gives you around 6 bits (26*2 letters + 10 numbers + some special characters ≈ 64 = 2^6), you'd need 256/6 ≈ 43 characters to exhaust the checked entropy, so up to that level it makes sense. If you use sentences instead of randomly generated characters, the entropy (in bits/character) is lower, so 100 characters might well make sense.
- deleted 1y ago
  [deleted]
- afiori 1y ago
  Which is why sha+bcrypt is always better than just bcrypt
bsimpson 1y ago
For years (and way more recently than is appropriate), the financial institution Schwab would silently truncate your password to 8 characters. If your password was 123lookatme, you could type 123lookaLITERALLYANYTHING and it would succeed.

Passwords are (or, rather, SHOULD be) cryptographically hashed rather than encrypted. It's possible to compute a hash over data which is longer than the hash input block size by feeding precious hashes and the next input block back in to progressively build up a hash of the entire data.

xx_ns 1y ago
bcrypt, one of the more popular password hashing algorithms out there, allows the password to be up to 72 characters in length. Any characters beyond that 72 limit are ignored and the password is silently truncated (!!!). It's actually a good method of testing whether a site uses bcrypt or not. If you set a password longer than 72 characters, but can sign in using just the 72 characters of your password, they're in all likelihood using bcrypt.
- deleted 1y ago
  [deleted]
- integralid 1y ago
  Yeah, that's why bcrypt is broken and shouldn't be used today. It had a good run, but nowadays we have better options like scrypt or argon2.
  - daneel_w 1y ago
    It's not broken. It's just potentially less helpful when it comes to protecting poor guessable passwords. bcrypt isn't the problem, weak password policies/habits are. Like bcrypt, argon2 is just a bandaid, though a tiny bit thicker. It won't save you from absurdly short passwords or silly "correct horse battery staple" advice, and it's no better than bcrypt at protecting proper unguessable passwords. Also, only developers who have no idea know what they're doing will feed plain-text passwords to their hasher. You should be peppering and pre-digesting the passwords, and at that point bcrypt's 72 character input limit doesn't matter.
    - kbolino 1y ago
      Bcrypt alone is unfit for purpose. Argon2 does not need its input to be predigested. It's easy for somebody who knows this to fix bcrypt, but silently truncating the input was an unforced error. The fact that it looks like and was often sold as the right tool for the job but isn't has led to real-world vulnerabilities. It's a classic example of crypto people not anticipating how things actually get used. (Otherwise, though, I agree)
      - daneel_w 1y ago
        Peppering is for protecting self-contained password hashes in case they leak. It's a secondary salt meant to be situated 1) external to the hash, and 2) external to the storage component the hashes reside in (i.e. not in the database you store accounts and hashes in). The method has nothing to do with trying to fix anything with bcrypt. You should be peppering your input even if you use Argon2.
        kbolino 1y ago
        Right, but peppering was not part of my comment. You can't always pepper, and there are different ways to do it. It's (mostly) orthogonal to the matter. You do not have to do any transformations on the input when using Argon2, while you must transform the input before using bcrypt. This was, again, an unnecessary and dangerous (careless) design choice.
        daneel_w 1y ago
        I don't understand your responses here. Clearly you are not familiar with what problem peppering solves, or why it's a recommended practice, no matter what self-contained password hashing you use. bcrypt, scrypt, Argon2; they are all subject to the same recommendation because they all store their salt together with the digest. You can always use a pepper, you should always use a pepper, and there's only one appropriate way to do it.
        1y ago
whyever 1y ago
Yes, in this case it would be easier to brute-force the key instead of the password, so the additional characters don't really help.
- Hackbraten 1y ago
  Brute-forcing the underlying key doesn’t help if you’re trying to mount a credential stuffing attack. Brute-forcing the password does.

FabHK 1y ago

Agreed. But since every character gives you around 6 bits (26*2 letters + 10 numbers + some special characters ≈ 64 = 2^6), you'd need 256/6 ≈ 43 characters to exhaust the checked entropy, so up to that level it makes sense. If you use sentences instead of randomly generated characters, the entropy (in bits/character) is lower, so 100 characters might well make sense.

deleted 1y ago
[deleted]
afiori 1y ago
Which is why sha+bcrypt is always better than just bcrypt

bsimpson 1y ago

For years (and way more recently than is appropriate), the financial institution Schwab would silently truncate your password to 8 characters. If your password was 123lookatme, you could type 123lookaLITERALLYANYTHING and it would succeed.