In password security, the longer the better. With a password manager, using more than 24 characters is simple. Unless, of course, the secure password is not accepted due to its length. (In this case, through STOVE.)
Possibly indicating cleartext storage of a limited field (which is an absolute no-go), or suboptimal or lacking security practices.
Is the maximum 24 characters because their database column is a VARCHAR(24)? That’s one of the first questions that I thought of. Sure, it doesn’t guarantee plaintext, but it’s a indicator that it may be stored plaintext, considering hashing doesn’t care about length. Or at the very least whoever has had eyes on this code doesn’t know shit about security, which makes me less confident in the product as a whole.
The only reason I can think of to have a maximum would be to save on bandwidth and CPU cycles, and even then 24 characters is ridiculously stingy when the difference would be negligible.
bcrypt hashes only the first 72 bytes. 24 characters is the max amount of 4 byte UTF8 characters when using bcrypt. Which is stupid because UTF8 is variable, but still, it’s a possible explanation.
A reason reason to switch to argon :)
To be fair, 24 is still a secure length for a password, and will probably be for another 5-10+ years.
Oh look, a free account!
Cryptographic hash functions actually have fixed runtime too, to avoid timing-based attacks.
So correct password implementations use the same storage and cpu-time regardless of the password.
I figured it was about the time spent transmitting. But the password should probably be hashed before sending as well as upon arrival at the server, correct?