I see this restriction quite often, and it makes no sense to me whatsoever. Am I missing a compelling reason for this practise, or is it an example of bad design?
You might want to run the password through Unicode-normalizing functions first (NFD or NFKD) but otherwise no.<p>Some sign-up forms don't even give you feedback on which characters are problematic. The Oracle Cloud one kept erroring with "you need one uppercase, one lowercase, and one number" when what it meant to say is "remove that tilde", that took a while to figure out.
Bad design, this seems to be part of many legacy systems.
People tended to make bespoke textual formats, instead of, how we do now, using properly escaped serialization like JSON.
And because they couldn't bother making a robust parser with escaping, they went the lazy route of just disallowing characters with special meaning.
Typically, they're using legacy software to store the password itself (e.g. database, mainframe, etc).<p>For a specific example Oracle Database has a very restrictive list of characters allowed in a user password. If you're using Database Users behind the scenes (even if not directly, but via an Oracle integration) you're subject to those same restrictions. Up until Oracle 11g passwords were also limited to 30 characters and a few releases before that were case-insensitive (!).<p>Is this a good reason? I'd argue, no, but I've worked at tons of organizations where "things that don't make sense" often have an explanation even if it isn't an explanation you're happy with. We should definitely push companies to use cryptographically secure one-way hashing functions with salts, and adjustable difficulty.
A relevant anecdote. During my younger more adventurous years. We used to try to peek over admins shoulders to figure out passwords for root. Not to do anything malicious but just as a act of geeky bravado. Naturally, they got savvy and prevented us from doing this.<p>The keyboards in the lab were heavily used and was noisy. The space bar, because of its shape, sounded distinctly different from the other keys. I stayed away from the admins when they entered the password like a decent citizen but listened in and found that the password was 7 characters long and also that the second and sixth characters were space (thanks to the different sound of the key). So .˽...˽.<p>I brute forced this using a shell script (since I has just learned how to write shell script), ran it overnight, and got in the next day.<p>So yes, I think there might, atleast in theory, be good reasons to avoid certain characters in a password.
I think there was a story about somebody locking himself out of macOS, because he couldn't enter Emoji on the login screen.<p>Also, since my password manager types letters one by one, I wouldn't use tabs or line feeds.<p>Maybe don't use grapheme clusters that have multiple valid encodings and make up for it by using a longer password instead?
As others said, it’s important that your users can enter their password on all devices they would want to use.<p>Because of that, outlawing the likes of line feed, carriage return and backspace (raw input on a tty will store those in passwords, but good luck entering them in a web form) makes sense, as does normalizing Unicode input (typing ‘é’ on their phone may produce a byte sequence that’s different from typing ‘é’ on their PC)<p>Apart from that, it should not be necessary. If, however, you don’t trust your programmers to do the right thing, you may want to rule out characters that are related to security incidents such as single quotes, and also may want to prevent users from entering strings that might get decoded to such strings such as ‘&quot;’.<p>That path can be endless, though. If you forbid ‘&’, because your programmers might accidentally html-decode it, should you guard against double html-decoding? URI-decoding and then uudecoding? Getting programmers you can trust to do the right thing and giving them the time to do so is the better option.
It's always annoying when a special character is required in a password, but "no, not that special character". Presumably those devs can't figure out how to escape special characters properly.
I suppose one legitimate reason might be to safeguard you in a scenario where you have to enter the password on a nonstandard keyboard? Also, if they can be easily confused with some other characters it might make sense to disallow them just to remove a headache for support staff trying to deal with people entering the password wrong (e.g. en-dash vs em-dash vs hyphen).<p>But they're probably just storing it in plaintext on some legacy system that can't handle certain characters. Or the plaintext goes through one of those systems on its way to being hashed and salted.
For characters between U+0020 and U+007E inclusive, there's no good reason at all, and it probably means that they're storing passwords in plaintext instead of hashing them, and that they aren't using parameterized queries to protect against SQL injection.<p>For characters outside that range, there is a good reason: it's hard to type those characters consistently across different platforms/systems, and they don't want you to lock yourself out over that.
let me quote NIST Special Publication 800-63B: <a href="https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret" rel="nofollow">https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret</a><p>> Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well.
I can think of a few reasons to exclude a character:<p>- Requires quoting or escaping in the shell or some other programming environment<p>- Hard to type on mobile keyboard.<p>- Not in a given person's touch-typing repertoire.<p>The correct way to think about password security is as randomly generating a binary string of the desired security strength/length and then encoding it. If you generate 16 random bytes, that's 128 bits of security whether you encode it with hex, base32 or base64.<p>Required characters also do little to improve security, since there is usually only 1 of each kind of required character, and it's often at the beginning or end. They don't cause the user to select a random string from a meaningfully larger space.
I think as long as the list is clear on what it must not have in advance and what it must have, it's not as big of a deal. Strings are a pain in the ass and come up with surprising ways to be frustrating, so I can totally get a restriction on some character.<p>What I cannot get is sites that make you play 20 questions to figure out their rules instead of just telling you, as in my experience, it leads to lousy passwords that meet only the bare minimum. I seem to recall some popular site (want to say it was AirBnB) which threw an error "password cannot contain name/username" for basically anything it didn't like, regardless of whether the password actually contained that, and it's very annoying.<p>It was one of the most welcomed changes to the password system at a former work place when I convinced the small team behind the authentication to put the requirements plain and simple and change from red to green as people met the requirements. We also added a passphrase helper that could be summoned if they missed requirements a few times which based on metrics got some fair use.<p>People generally want to do well by security and it's on their mind, but no one wants to look stupid because they can't think of a password that meets unknown requirements. Make it clear what's expected, and even a nudge towards how to think of good passphrases, and you'll get happy people using your site.
I don't remember exactly which sites, but I run into the problem every so often with a handful where I'm prompted to change my password according to vague guidelines that say I usually need special characters, without saying which ones it accepts.<p>I change my password with something randomly generated by my password manager, and the site accepts it, and as far as I know I'm good to go. Then next time I try to log into the website, it doesn't accept the password it previously (falsely) accepted before, and I have to reset it again and play the guessing game of what special character it didn't like. Madness.
It would be interesting (and helpful) to see some real-life examples of which Websites disallow what characters. Then maybe we could hazard an explanation.<p>Possibly they're preparing for password entry on more ubiquitous devices with limited keyboards? (ATMs, credit card keypads).
IMO you shouldn't be interpreting passwords at all, besides maybe enforcing a minimum length of 4-6 characters. Other than that you receive a string from the user and you just hash it as is.
I see a lot of mention of unicode and unusual space/null characters here which makes sense, but I was not allowed to use @ in my pw for my Amex account, and that seems absolutely crazy.
If the character can not be hashed - outside of that, no reason at all.<p>Although you should probably not allow "1234" as passwords or anything on the top 100 list for that matter.
I do this on IRC to prevent people from using characters that clients will interpret. It's not safer, but it prevents a ton of password support issues.
it's very important when you're storing passwords in plain text, so typically it's a sign the website is dangerously insecure, though sometimes it's also just some product manager going "well everyone else does it, so it must be important".<p>That said, I did actually run into an instance where having ";-- in your password would trigger the WAF during login and because we needed to ship ASAP the easiest way to get around that was to ban ; in passwords. I don't think we ever went back to fix that one...
Let's start at the edgest of cases.<p>Some emoji, for example, are combinations of multiple other emoji, and a given combined emoji may not be uniquely represented by a sequence of codepoints. In the pathological case, this could mean that an OS update on the user's system changes the composition of the same emoji, which might make it impossible for them to input their password. It is probably prudent for a system to disallow emoji passwords.<p>One step away from Emoji, Unicode also allows for other m̸̱̜̅ͅȋ̴̩̠̀s̸̺͐c̶͈͇͉̐͛̚h̸̤̣̆i̴͍͍͒͌e̴̲̽̓f̸̞̽̊. Chances are, full-on Zalgo passwords can lead to problems. Again, there are probably prudent reasons to restrict some characters. On the other hand, those modifiers exist for a reason, and disallowing phrases in the user's native language doesn't make for great UX.<p>Towards the more common use of Unicode, there is a pretty good _practical_ reason to restrict the use of some non-ASCII characters: if your system accepts ç, ö and ø as characters in passwords, and non-technical users venture into a part of the world where the keyboard layout doesn't, your helpdesk is going to have to deal with the occasional annoyed customer. From a systems design perspective, those characters seem fine -- operationally, they may cause headaches.<p>Finally, we've arrived at printable ASCII characters. Restrictions on maximum length (usually 6 or 8 characters), and on certain characters (%, & or :) tend to be based on interactions with legacy systems (e.g. DES crypt() used to have an 8-character minimum), or on bad input handling. Either way, it's probably a bad sign.
I once used a special character in my login password (on Ubuntu I think) but the keyboard settings at the passwd prompt happened to be set differently from the ones at the (graphical) login manager at boot. So in the one case, something like 'e was interpreted as é and in the other case it wasn't.<p>I think it took me about five reboots in single-user mode and password resets before something clicked. I wish Ubuntu would not have allowed special characters. :)
On mobile, keyboards typically auto capitalize the first letter of the first word.<p>So if your password is "password", it will get entered in as "Password" - and the user will get confused why their username/password aren't logging them in.<p>So a UX pattern is to actually lowercase the first letter on the backend.