6 ms·

In what way does a password length limit suggest plain-text storage?

inetknght 7y ago
In the same way that the best one-way hash algorithms can accept arbitrarily large inputs and produce a constant-sized digest.
- SilasX 7y ago
  True but I thought you’d want to have some size limit regardless, if for no other reason than choking up the connection with a huge one.
  - inetknght 7y ago
    Sure, but "some size limit" can be as big as 500 or 1000 bytes. "Choking up the connection" won't be for very long at all. Even on a 2400 baud modem, you're talking only a few seconds to transmit a kilobyte of password. On modern cell networks or especially broadband connections, you pretty much won't choke the connection at all with a 1000-character password.
    - johndough 7y ago
      To add to that, the login page (which contains nothing but two fields for email and password) weighs in at 1.5 MB, so bandwidth clearly is not an issue for PayPal.
      - SilasX 7y ago
        Which still doesn't refute the need for a limit, and a large part of why I didn't defend a 24-character limit.
    - SilasX 7y ago
      I agree, which was I was only criticizing the point against "there should not be a limit at all" -- I don't know what you're disagreeing with that I said.
aaomidi 7y ago
Because there's usually not a reason to limit it to something that low.
- humaniania 7y ago
  A previously defined field length on a production database would be a more simple explanation, no?
  - aaomidi 7y ago
    No because the length of that field is static. Hashing algorithms (at least the ones you should use) will create a static length hash no matter the size of the password. The only time length matters is if the hashing algorithm has a limit (which is usually pretty high), or if you're storing these values encrypted/plain text.
    - meowface 7y ago
      Or because you don't want to risk users forgetting very long passwords. (Everyone should be using a password manager, but sadly that isn't the case.) That's generally the reason that limit is set.
      - rocqua 7y ago
        That certainly flies in the face of most recent recommendation. Recent NIST guidelines say not to do this, and NIST isn't really known for being adventureous. The current best practice is for people to use passphrases rather than complicated passwords. For this, a password length limit of 24 is simply not enough.
        meowface 7y ago
        I'm no advocate of it; just explaining what's very likely their rationale, as opposed to them storing passwords in plaintext. Plaintext password storage still happens, but you wouldn't see that at a company like Paypal. (Plaintext credentials may be unintentionally present elsewhere, like debug logs, but a company like that isn't going to be so incompetent as to store them in plaintext in the database.)
rocqua 7y ago
One reason why one might have a password length limit (especially such a low one) is because it is stored in a fixed size 'string' field in a database. This used to be a common configuration of authentication mechanisms where the password was stored plaintext. Now, I don't think paypal is _actually_ storing passwords in plaintext. However, it is the first reason that comes to mind when this kind of limitation exists. My most generous explanation of this scheme is that, at some point, paypal used plaintext as the backend for authentication. Now when they moved to a better scheme for the backend they never updated the length limit. Then this limit of 24 slowly invaded all code on the front-end of auth and changing it is seen as to big an issue. I'd expect some reasons like 'longer passwords are harder to remember' and 'network performance' are probably used internally as rationalizations for why no one starts trying to fix this. Alternatively, they could really believe in a 'long passwords are harder to remember' or 'long passwords would induce a lot of performance overhead'. However, as far as I know, there are no reasons that fall anywhere near 'best practice' that would support a password length limit of 24.

In the same way that the best one-way hash algorithms can accept arbitrarily large inputs and produce a constant-sized digest.

SilasX 7y ago
True but I thought you’d want to have some size limit regardless, if for no other reason than choking up the connection with a huge one.
- inetknght 7y ago
  Sure, but "some size limit" can be as big as 500 or 1000 bytes. "Choking up the connection" won't be for very long at all. Even on a 2400 baud modem, you're talking only a few seconds to transmit a kilobyte of password. On modern cell networks or especially broadband connections, you pretty much won't choke the connection at all with a 1000-character password.
  - johndough 7y ago
    To add to that, the login page (which contains nothing but two fields for email and password) weighs in at 1.5 MB, so bandwidth clearly is not an issue for PayPal.
    - SilasX 7y ago
      Which still doesn't refute the need for a limit, and a large part of why I didn't defend a 24-character limit.
  - SilasX 7y ago
    I agree, which was I was only criticizing the point against "there should not be a limit at all" -- I don't know what you're disagreeing with that I said.

aaomidi 7y ago

Because there's usually not a reason to limit it to something that low.

humaniania 7y ago
A previously defined field length on a production database would be a more simple explanation, no?
- aaomidi 7y ago
  No because the length of that field is static. Hashing algorithms (at least the ones you should use) will create a static length hash no matter the size of the password. The only time length matters is if the hashing algorithm has a limit (which is usually pretty high), or if you're storing these values encrypted/plain text.
  - meowface 7y ago
    Or because you don't want to risk users forgetting very long passwords. (Everyone should be using a password manager, but sadly that isn't the case.) That's generally the reason that limit is set.
    - rocqua 7y ago
      That certainly flies in the face of most recent recommendation. Recent NIST guidelines say not to do this, and NIST isn't really known for being adventureous. The current best practice is for people to use passphrases rather than complicated passwords. For this, a password length limit of 24 is simply not enough.
      - meowface 7y ago
        I'm no advocate of it; just explaining what's very likely their rationale, as opposed to them storing passwords in plaintext. Plaintext password storage still happens, but you wouldn't see that at a company like Paypal. (Plaintext credentials may be unintentionally present elsewhere, like debug logs, but a company like that isn't going to be so incompetent as to store them in plaintext in the database.)

rocqua 7y ago

One reason why one might have a password length limit (especially such a low one) is because it is stored in a fixed size 'string' field in a database. This used to be a common configuration of authentication mechanisms where the password was stored plaintext. Now, I don't think paypal is _actually_ storing passwords in plaintext. However, it is the first reason that comes to mind when this kind of limitation exists. My most generous explanation of this scheme is that, at some point, paypal used plaintext as the backend for authentication. Now when they moved to a better scheme for the backend they never updated the length limit. Then this limit of 24 slowly invaded all code on the front-end of auth and changing it is seen as to big an issue. I'd expect some reasons like 'longer passwords are harder to remember' and 'network performance' are probably used internally as rationalizations for why no one starts trying to fix this. Alternatively, they could really believe in a 'long passwords are harder to remember' or 'long passwords would induce a lot of performance overhead'. However, as far as I know, there are no reasons that fall anywhere near 'best practice' that would support a password length limit of 24.