5 ms·

A constraint on password length is often suggestive that the password is not being stored securely.

by peteretep 9y ago

user5994461 9y ago
That's simply not true.
- jessaustin 9y ago
  Yes it totally is true. Hashes are a standard length, and you can feed any length passphrase into the hash algorithm. It wouldn't surprise me to see passphrases limited to e.g. 256 chars anyway, but 27 smells very bad. What system limitation leads to this particular number? It smells like a DB column width to me.
  - user5994461 9y ago
    Just because there is a limitation on password length doesn't imply they store the password in clear text.
    - nthcolumn 9y ago
      He never said anything about 'clear text' you did and yes that is usually how it is with this 'tell'. It might be some other weakness. Smells like homebrew security. Nice. They are doing it wrong and the wrong shows. That is definitely going in my initial survey.
    - peteretep 9y ago
      It may not imply it, but it strongly suggests it.
    - Piskvorrr 9y ago
      It does not mean they store the password in clear text, but the implication is surely there. (It does not mean what you think it means.)
  - thaumasiotes 9y ago
    Password hashes are specifically designed to be computationally intensive. You can feed any length of password into a hash, but the longer the password is, the more work you have to do. "No length restriction on passwords" is a common and valid report on HackerOne, because servers that do store passwords securely can be DoSed by someone providing a long password and forcing the server to hash it.
    - wongarsu 9y ago
      That is an important consideration, but it still sets reasonable password length limits in the hundreds or thousands of characters.
      - bigiain 9y ago
        NIST's latest recommendations say "at least 64 characters". I doubt there's anyone who can make a strong argument that "64 characters isn't enough", and I doubt even intentionally computationally expensive password hashing is going to end up with significant resource usage with 64 or 128 character strings. I wouldn't want my shared hosting WordPress site with a password plugin to need to calculate the bcrypt hash of the entire text of War And Peace, bit I suspect the difference between bcrypting "password123" and a random 64 or 128 character string is insignificant enough to be ignored (but I've never tried benchmarking it, so I'm open to changing my mind here if anyone has links to benchmarks that show otherwise...)
        thaumasiotes 9y ago
        I usually see recommendations for a 72 character limit. I doubt there's any particular reason for 72, but as you say, it's enough. Login attempts (should) get rate limited independently of password length limits, which makes the difference between hashing 8 characters and hashing 72 characters even less meaningful.
        CodesInChaos 9y ago
        I'd guess it's because bcrypt only supports 72-byte inputs (though there are workarounds, like pre-hashing)
- sillysaurus3 9y ago
  Well, they're not wrong. Companies do store plaintext passwords as a customer service tradeoff. (A bad one, but they do it.) Chopping the length of a password to <32 chars is pretty correlated.
  - maaark 9y ago
    and storing plaintext passwords is unacceptable.
    - sillysaurus3 9y ago
      That's not true in every case. If you're just throwing it into a DB, then yes. But if you're encrypting it and storing it on an isolated server with the decryption keys on a separate server, it's not a huge deal. Look, people on HN make a massive deal about passwords. One of my most shocking discoveries starting as a pentester was that "storing passwords in plaintext" would be a low-severity finding at best. Medium through critical vulns are reserved for findings that can own an app. That's how little password storage matters. If you're relying on UPS preserving the secrecy of your 21-character master password that you're using across all your websites, you're doing it wrong. Yet the vast majority of users will do exactly that. The way to protect them is for critical services to use 2FA, which they do -- email, phone, insurance, etc all use 2FA or separate 4-digit passcodes now (USAA). There have been so many password database leaks, yet the world moves forward. What is unacceptable is for Blue Cross to leak all your PII, yet the world moved on from that. CloudFlare leaked a huge amount of sensitive info. All of those matter way more than some password leaks. If someone is going to target you, here's the most likely method: https://news.ycombinator.com/item?id=14919845 https://news.ycombinator.com/item?id=14919845
      - Piskvorrr 9y ago
        If you're using the outlined method, you're very, very far from storing it in plain-text; much further than the woefully common `sha1(passwordtext) // voila, secure!`.
      - Jwarder 9y ago

A constraint on password length is often suggestive that the password is not being stored securely.

user5994461 9y ago

That's simply not true.

jessaustin 9y ago
Yes it totally is true. Hashes are a standard length, and you can feed any length passphrase into the hash algorithm. It wouldn't surprise me to see passphrases limited to e.g. 256 chars anyway, but 27 smells very bad. What system limitation leads to this particular number? It smells like a DB column width to me.
- user5994461 9y ago
  Just because there is a limitation on password length doesn't imply they store the password in clear text.
  - nthcolumn 9y ago
    He never said anything about 'clear text' you did and yes that is usually how it is with this 'tell'. It might be some other weakness. Smells like homebrew security. Nice. They are doing it wrong and the wrong shows. That is definitely going in my initial survey.
  - peteretep 9y ago
    It may not imply it, but it strongly suggests it.
  - Piskvorrr 9y ago
    It does not mean they store the password in clear text, but the implication is surely there. (It does not mean what you think it means.)
- thaumasiotes 9y ago
  Password hashes are specifically designed to be computationally intensive. You can feed any length of password into a hash, but the longer the password is, the more work you have to do. "No length restriction on passwords" is a common and valid report on HackerOne, because servers that do store passwords securely can be DoSed by someone providing a long password and forcing the server to hash it.
  - wongarsu 9y ago
    That is an important consideration, but it still sets reasonable password length limits in the hundreds or thousands of characters.
    - bigiain 9y ago
      NIST's latest recommendations say "at least 64 characters". I doubt there's anyone who can make a strong argument that "64 characters isn't enough", and I doubt even intentionally computationally expensive password hashing is going to end up with significant resource usage with 64 or 128 character strings. I wouldn't want my shared hosting WordPress site with a password plugin to need to calculate the bcrypt hash of the entire text of War And Peace, bit I suspect the difference between bcrypting "password123" and a random 64 or 128 character string is insignificant enough to be ignored (but I've never tried benchmarking it, so I'm open to changing my mind here if anyone has links to benchmarks that show otherwise...)
      - thaumasiotes 9y ago
        I usually see recommendations for a 72 character limit. I doubt there's any particular reason for 72, but as you say, it's enough. Login attempts (should) get rate limited independently of password length limits, which makes the difference between hashing 8 characters and hashing 72 characters even less meaningful.
        CodesInChaos 9y ago
        I'd guess it's because bcrypt only supports 72-byte inputs (though there are workarounds, like pre-hashing)
sillysaurus3 9y ago
Well, they're not wrong. Companies do store plaintext passwords as a customer service tradeoff. (A bad one, but they do it.) Chopping the length of a password to <32 chars is pretty correlated.
- maaark 9y ago
  and storing plaintext passwords is unacceptable.
  - sillysaurus3 9y ago
    That's not true in every case. If you're just throwing it into a DB, then yes. But if you're encrypting it and storing it on an isolated server with the decryption keys on a separate server, it's not a huge deal. Look, people on HN make a massive deal about passwords. One of my most shocking discoveries starting as a pentester was that "storing passwords in plaintext" would be a low-severity finding at best. Medium through critical vulns are reserved for findings that can own an app. That's how little password storage matters. If you're relying on UPS preserving the secrecy of your 21-character master password that you're using across all your websites, you're doing it wrong. Yet the vast majority of users will do exactly that. The way to protect them is for critical services to use 2FA, which they do -- email, phone, insurance, etc all use 2FA or separate 4-digit passcodes now (USAA). There have been so many password database leaks, yet the world moves forward. What is unacceptable is for Blue Cross to leak all your PII, yet the world moved on from that. CloudFlare leaked a huge amount of sensitive info. All of those matter way more than some password leaks. If someone is going to target you, here's the most likely method: https://news.ycombinator.com/item?id=14919845 https://news.ycombinator.com/item?id=14919845
    - Piskvorrr 9y ago
      If you're using the outlined method, you're very, very far from storing it in plain-text; much further than the woefully common `sha1(passwordtext) // voila, secure!`.
    - Jwarder 9y ago