My favorite is when it must have punctuation, but certain punctuation is silently banned, so I have to keep refreshing my password generator until it gives me an acceptable combination.
My favorite is when it must have punctuation, but certain punctuation is silently banned, so I have to keep refreshing my password generator until it gives me an acceptable combination.
I came across a "special character" requirement while creating an account. The client validation was not the same as the server validation. The client proceeded as if my account was created, but it never was. The client functioned without an account until it was closed. I asked the creator what their app's problem was, why did I need to keep resetting my password, then be told that I don't have an account, and have to create it anew.
They would not believe I was creating an account and using the device, because their own logging was so terrible.
I had to send them a screen recording from me using this abomination, and only then was I told "you're using the wrong special characters". They helpfully gave me some examples of allowed special characters, which then would pass the server validation.
I wish they would have gotten rid of the account requirement, as the device and client software seemed to work fine without them.
Sometimes when that happens, and any of `:({ |&;` are on the no-no list, I try bypassing the client validations and setting my password to a shell fork bomb. So far as I'm aware it hasn't broken anything yet, but I'm determined to keep trying.
Somewhat unrelated, is there any technical reason certain punctuation might be banned? I can understand maybe not allowing letters with diacritics or other NON-ASCII chars but why would a system reject an @ sign or bracket > for example?
Depending on the protocol they can be url encoded or even helpfully html encoded; the same password can be used over different protocols. It's the best to not use punctuation by default (length supplies more entropy than charset), I add -0 at the end to make dumb password policies happy.
Often, the same ones with limited punctuation also have length limits, so maximizing the character options is the only way to maximize entropy.
A lot of the restricted stuff is cargo-cult fear of symbols that could be used in SQL-injection or XSS attacks.
A properly-coded system wouldn't care, but the people who write the rules have read old OWASP documents and in there they saw these symbols were somehow involved in big scary hacks that they didn't understand. So it's easier to ban them.