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.
We have a customer, a big international corporation, that has very specific rules for their intranet passwords:
I can only assume that whoever came up with these rules is either an especially demented BofH, or they have some really really weird legacy infrastructure to deal with.
I am a designer, but I once did a project with a very very major and recognizable tech corporation that, no joke, implemented an 8 character limit on passwords for storage reasons.
This company made in the tune of tens of billions of dollars per year, and they were penny-pinching on literal bytes of data.
I can’t say who it is, but their name begins with ‘M’ and ends in ‘cAfee.’
Whoever the company is, we have to assume it’s not a security-related company. Because, surely, none of those would do that ever.
If password length affects storage size then something has gone very wrong. They should be hashed, not encrypted or in plaintext.
No repeats??? Like, you cant have ‘aaaa123@’ as a password?
You’re just making it easier to brute force…
Since the password has to be changed every two months, I would assume that it means no repeating previously used passwords.
It also says “must not be the same as any of the last seven passwords used” so I can only take “no repeats” to mean no repeated characters.
Requiring passwords to be exactly 8 characters is especially ridiculous because even if they’re cheaping out on bytes of storage, that’s completely cancelled out by the fact that they’re storing the last seven passwords used.