UPS supplier's password policy flip-flops from unlimited, to 32, then 64 characters A major IT hardware manufacturer is correcting a recent security update after customers complained of a password character limit being introduced when there previously wasn't one. CyberPower Systems, which sells uninterruptible power supplies (UPS) and surge protectors, confirmed to The Register that following pushback from …
Our virgin is a 10 character password, which annoys the misses as the "standard" for things like this is 11. Try adding that 11th character when typing in the password and it it will no match. Not tried recently to see if their password reet can now take more than 10 characters or not
Or until it breaks. There was a site I used. It stored financial data, so I wanted a good password on that. At one point, they simply changed their length limit without telling anyone, but they didn't change it on the login page. While new accounts could not be registered with a password longer than twenty characters, my longer one could still be used to log in. So naturally, I didn't notice that they had done this until some time later when someone put the same limit on the login page's password field. Even now, I don't know if that was intentional or not because their page does not say "maximum of twenty characters" it just stops accepting new characters when you've typed twenty.
hotmail.com did the same thing a decade ago, but instead of stopping accepting characters, they would only hash the first N and throw the rest away. Then they changed to only accepting N characters overwriting the Nth character with your continued typing... It took me several days to figure out a way around that one...which was to stop at the Nth character.
Welcome to our new system & I did have a client ask me during the migration "What's the exclamation mark?".
Staff are already printing barcode labels (In some cases that's justified with having to sign into RF barcode guns).
Writing the password down is, in most cases, a good thing - better than just using "Password123!" everywhere
If N. Korean hackers can read the post-it note on my monitor - I have bigger problems than 32 or 64 char limits
I'd argue that a bit of paper stuffed in the back of my phone case is more secure than the Super-secure-corporate-approved authenticator app - that is one buffer overflow form being available to every other Android app in the Play Store, or my bank that quaintly thinks a text message is somehow secure.
My guess is that the password is hashed in some form using SHA256, which produces a 32 byte output. My guess is that someone therefore thinks that inputting more than 32 characters results in a reduction of entropy, and should be avoided. This is wrong because the input characters don't have 8 bits of entropy each, 2 bits would be typical for english words, 3 or 4 if you make an effort with funny characters and random upper/lower case. Hashing a 48 character password will very likely increase the entropy, despite the apparent reduction in length.
I think 256 characters would be a sensible maximum.
>My guess is that someone therefore thinks that inputting more than 32 characters results in a reduction of entropy, and should be avoided. T
Unlikely given the high professional standards and deep knowledge of cryptographic fundamentals throughout the software industry - especially among web developers
The worst password thing I ever encountered was where the password field on the form where you register allows longer passwords than the login form. Now you can't log in because you run out of space. The other worst password thing I ever encountered is on one of our servers: the rules for allowable passwords are recorded in a set of encyclopedias. You have a better chance of winning the lottery three times in a row than generating an acceptable password. There's also a good 100% chance of locking your account while constructing a password. I've resorted to the unsafe practice of just replacing characters in the old password with similar ones (e.g. @!A-1934(*&gerqpwidaskl becomes #@B+2045)&hfs......)
My “favourite” is the iterative error messages, with no information that covers all requirements. (Thankfully I haven’t seen it for a while.)
1st attempt: too short
2nd attempt: you need both lower- and uppercase letters
3rd attempt: you need a special character
4th attempt ‘/‘ is not permitted.
Etc etc
The icing on the cake is when you have to do a puzzle captcha puzzle for each iteration
Your forgetting the one where the admin console doesn't use KEYMAP and assumes a US keyboard layout - but the login console, and you used special chars
Or the RaspberryPi which asummes a UK keyboard when you enter the hidden-from-view passwd at first boot. Tricky if you are working in the colonies with their weird keyboard customs.
What do you even go online for? All 8 or so of the CyberPowers I bought a few years ago had their battery charger fail as soon as the warranty ran out. Some went to 50% voltage, some to 150%. I finally got all of their destroyed lead acid batteries dropped off at hazmat/recycling.
The one CyberPower UPS I have owned seemed to work fine for years - until an actual outage, at which point it died within a couple seconds. The battery was worn out, but wasn't designed to be user-replaceable.
My APC, however, is still ticking away and has saved downtime on many occasions.
The only limits I can see that make sense are limits to prevent a Denial of Service attack, like allowing up to 256 characters to mitigate a denial of service attack on bcrypt for example. How did anyone think that 32 characters is the correct answer? That couldn't even hold a passphrase like "The village idiot could think of a better password length limit."
I continue to wonder about this. Unless you're storing passwords in clear text, is there any reason for a limit on password length? (Aside from the one mentioned in the Fine Article : submitting a gigabyte-long password to deny service while the server hashes said password.)
The above is an honest question, by the way. I asked it in these fora quite a while back, got downvotes, but no actual answer. My assumption has always been that any site with a low password limit and limitations on special characters is storing the password as plain text. Which is a rather scary fraction of sites.
Also : has anyone but a third party ever messed up security?
It is my automatic fear as well. I have a feeling that many sites with a limit are properly hashing them, rather than storing in plain text or symmetrically encrypting them, but there is no way to know that. We also know that many bad sites do one of those things. The other clue that makes me assume that is if they say that some characters are not allowed in a password. If it's non-ASCII characters, then fair enough I am willing to assume that the developer was worried about Unicode encoding and probably didn't have to. If it's trailing or leading whitespace or unprintable characters, I can understand that. If it's ', ", ?, or *, I'm concerned now.
In theory, there is no reason at all to limit the length of a passphrase to less than, say, a thousand Unicode characters. You may not gain any further security by choosing a passphrase longer than some value (e.g., hash size) but it won’t hurt either.
Practically things might be different, and I guess that’s the reason for some bodies recommending length limits. The hashing implementation could have bugs (think a fixed-size buffer for the password) and break/crash/allow unauthenticated RCE on trying to hash the oversized password; imposing a sensible length limit avoids that risk.
Regarding the combination of short passwords and disallowing especially the single quote… yeah, either passwords stored in plain text (and „oh, no, we don’t have SQL injection issues“. Sure.) or some stupid corporate policy. Or both.
There has to be SOME limit. You need to allocate a buffer to receive the typed password, for a start.
If there is no publically stated limit, then each implementation will be different, and someone's 786 character password won't work after Joe rewrites the input method and uses a 512 byte buffer instead of 1K.
Not really. If you're getting the password from an HTML form, then it comes through as HTTP post data. The memory for that request is automatically allocated. In most backend languages, you don't have to allocate memory for a string because it's already there. If you're using something where you ordinarily would, C for instance, you still don't have to allocate a buffer because you can just update the hash in a loop, assuming that your hash algorithm is like a lot of others and allows this. There would still be a limit, but it would be whatever your server sets as the maximum size of a post request before it rejects it which is often at least a megabyte.
I don't object to a limit intended to prevent a password from being ludicrously long. 32 characters, almost certainly implemented as 32 bytes and Unicode...well who knows if it works or not, is not that.
I can't use an easy-to-remember but hard-to-guess pass phrase like KeirStarmerIsTheBestPrimeMinisterTheUkHasEverHad?
Reminds me of the time I was at uni and we were given the password to a shared account (yes, really).
We were told the password was Aardvark.
Turns out it was Aardvark spelt incorrectly (as Aardvaak). Certainly kept us out (and in the pub).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
