4 ms·
A previously defined field length on a production database would be a more simple explanation, no?
by humaniania 7y ago
A previously defined field length on a production database would be a more simple explanation, no?
- aaomidi 7y agoNo 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 agoOr 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 agoThat 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 agoI'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.)
- aaomidi 7y agoWe've literally seen larger companies be more incompetent. There's no reason PayPal is excluded from this.
- meowface 7y agoCan you show me a larger payment-focused company that's been revealed to be storing passwords in plaintext within the past 5 years? Not saying there's not a ton of incompetence, but that's a very specific level of incompetence.
- aaomidi 7y agoWhy does it have to be payment focused? There's tons of big tech companies that have done this. Enjoy: https://github.com/plaintextoffenders/plaintextoffenders/blob/master/offenders.csv https://github.com/plaintextoffenders/plaintextoffenders/blo... It's not difficult to find them
- meowface 7y agoI'm just saying a company like Paypal which is both massive and dealing with something extremely sensitive (money) isn't going to make such a ridiculous mistake. I'm definitely no fan of theirs; I'm just saying it's silly for the initial poster to speculate the password length restriction is there because they're storing them in plaintext. Plaintext password storage definitely still is common, unfortunately, but you're not going to see it at a place like Paypal or Bank of America or Stripe in 2020. Or even 2010.
- rocqua 7y agoHence, the presence of a password limit suggests the used of a fixed length field in a DB that stores values in plain-text. The passwords being stored encrypted with a fixed length cyphertext would make 24 a weird number. That would suggest something like AES-192. Without storing the IV in the same field. Moreover, encrypted passwords are worse than hashed passwords. Because it means you need to secure the encryption key. Whereas with a salted hash, there is only brute force for recovering plain-text passwords.