8 ms·

Ask HN: Is there a good reason for disallowing some characters from a password?

38 points by andy_herbert 4y ago

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?

grishka 4y ago
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.
brendoncarroll 4y ago
I can think of a few reasons to exclude a character: - Requires quoting or escaping in the shell or some other programming environment - Hard to type on mobile keyboard. - Not in a given person's touch-typing repertoire. 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. 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.
blitzar 4y ago
If the character can not be hashed - outside of that, no reason at all. Although you should probably not allow "1234" as passwords or anything on the top 100 list for that matter.
hulitu 4y ago
Try to type a password with accents on an english keyboard
4oo4 4y ago
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. 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.
csydas 4y ago
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. 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. 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. 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.
dioxide 4y ago
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.
RicoElectrico 4y ago
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.
- bombcar 4y ago
  This is exactly it. Something somewhere broke on someone's password (think Bobby Tables) and so they forbid the character that done caused it.
- tgv 4y ago
  They just don't know how to get text unscrambled from a browser or an app's text box in server memory. That always makes me think they don't understand the design of what they're using, so they just forbid certain characters. When they forbid backslashes and quotes, it's even better: someone didn't know how to use query parameters or escape database values. It's a sign that their software is as secure as a "watch out for the dog" sign.
brodouevencode 4y ago
My credit card company does this, and it's infuriating
tiffanyh 4y ago
On mobile, keyboards typically auto capitalize the first letter of the first word. 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. So a UX pattern is to actually lowercase the first letter on the backend.
- CJefferson 4y ago
  Facebook actually do try flipping the capitalisation of your password (in case you have caps-lock on), and the capitalisation of the first letter (to cover this exact case): https://security.stackexchange.com/questions/68013/facebook-password-lowercase-and-uppercase https://security.stackexchange.com/questions/68013/facebook-... While this technically slightly lowers security (they are trying 4 passwords built from the one you typed in), I don't think that's significant, and I imagine it greatly improves user experience.
- tgv 4y ago
  I think browsers no longer do that when a field is labeled as a password. But there's always someone who still uses an Android 4 phone with Samsung Internet 0.37beta1.
  - joshenders 4y ago
    For those living 10 years in the past, a degraded experience is probably par for the course and a fair forcing function to move on. You have draw the line somewhere and degrading the majority’s experience for the minority’s benefit is an unusual trade-off.
- lolinder 4y ago
  Both OSes have different keyboard configs for different field types, and at least on Android it most definitely does not capitalize the first letter on a password field. Maybe some third party keyboards do? Even so, my gut says that mangling passwords on the backend is a really bad solution that may come back to bite you in ways you don't expect.
- joshenders 4y ago
remram 4y ago
You might want to run the password through Unicode-normalizing functions first (NFD or NFKD) but otherwise no. 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.
- toast0 4y ago
  > You might want to run the password through Unicode-normalizing functions first (NFD or NFKD) but otherwise no. If you do this, you should really save the version of the normalizing table you used, since they change over time.
  - remram 4y ago
    Damn, I didn't even think about that. On the other hand I feel like if your password includes the kind of characters for which normalization rules are changing, you'll just have to reset it if it breaks. Tracking the version of the table is more than I'm willing to do.
- avinassh 4y ago
  > You might want to run the password through Unicode-normalizing functions first (NFD or NFKD) but otherwise no. what are these and why do you need to do it?
  - remram 4y ago
    Some Unicode characters can be represented with different sequences of Unicode codepoints. For example é can be a single codepoint U+00E9 "latin small letter E with acute" or it can be the two codepoints U+0065 "latin small letter E" and U+0301 "combining acute accent". This is independent of the Unicode encoding, which turns those codepoints into bytes, for example using UTF-8 this gives C3A9 or 65CC81. Users don't really have control about what their keyboard/application is putting in the text field when they press the button, and obviously the hash of those is different so the password wouldn't match. Normalization is the process of turning the characters into its composed form (in my example "\u00E9") or the decomposed form ("\u0065\u0301"), so you can then compare your codepoints/bytes/hashes. https://en.wikipedia.org/wiki/Unicode_equivalence#Normalization https://en.wikipedia.org/wiki/Unicode_equivalence#Normalizat...
pestatije 4y ago
It forces the use of a new password specific to that site. Reusing passwords is considered bad for security.
- joshenders 4y ago
  Can you elaborate? It seems like it just enforces a specific type of password which is entirely reusable.
- wizofaus 4y ago
  Yes but that's a terrible way to enforce it. I've said here before I'd actually like the browser to forbid users from reusing passwords when signing up to new sites. I'm guessing there is actually a plugin that does it.
lexicality 4y ago
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". 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...
- daneel_w 4y ago
  > it's very important when you're storing passwords in plain text, so typically it's a sign the website is dangerously insecure ... This is a misconception. Password length is far more important than allowing a few "tricky" non-alphanumerics. It aids entropy, but it's not some security silver bullet. Also, if the web service you're using is storing undigested passwords then all bets are off.
prof-dr-ir 4y ago
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. 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. :)
Someone1234 4y ago
Typically, they're using legacy software to store the password itself (e.g. database, mainframe, etc). 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 (!). 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.
- tzs 4y ago
  > Typically, they're using legacy software to store the password itself (e.g. database, mainframe, etc) I've heard banks and other financial institutions use the "our ancient mainframe only allows 8 characters in account passwords" excuse or "our ancient mainframe database can only handle 8 characters in the password column", and find it extremely hard to believe. First of all, I find it hard to believe that each customer has a user account on the mainframe, and so the mainframe's restrictions on account passwords is irrelevant. Your banking account is going to be entirely something defined by the database. Second, I find it hard to believe that they are running their web server on their ancient mainframe OS. The web server is going to be running on something more modern. Users have to go through that to do online banking, and the account system on that can be totally separate from whatever account system is running on the backend banking system. Your user name (if their online banking uses something other than you account number) and you password for online banking should be entirely handled on the Unix or Unix-like or Windows Server that is running their web-facing stuff. The ancient mainframe stuff should never see it.
  - Someone1234 4y ago
    > I find it hard to believe that each customer has a user account on the mainframe Why? Do you actually have any experience in this area? I do, and I can tell you, they do exactly that. Then multiple systems integrate with that mainframe, often using the user account as the unique identifier for the entire organization. Migrations are an absolute nightmare. > Users have to go through that to do online banking, and the account system on that can be totally separate from whatever account system is running on the backend banking system. It can be, but it isn't. Thus, the problem. Honestly this type of "hardly believe" take is what every new employee right out of college (or myself 15 years ago) when they come up with ten thousand "simple" ideas for improvement without any organization, political, or system understanding. Then they act confused when their ideas aren't instantly implemented, because they don't even understand what it is they're proposing or why it is complicated. Banks have been trying to get off of mainframes for 30-years or more at this point, spent tens of millions of dollars, but had someone just told them to "run a web server in front of it" this could all have been avoided.
RedNifre 4y ago
I think there was a story about somebody locking himself out of macOS, because he couldn't enter Emoji on the login screen. Also, since my password manager types letters one by one, I wouldn't use tabs or line feeds. Maybe don't use grapheme clusters that have multiple valid encodings and make up for it by using a longer password instead?
GnarfGnarf 4y ago
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. Possibly they're preparing for password entry on more ubiquitous devices with limited keyboards? (ATMs, credit card keypads).
_dain_ 4y ago
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). 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.
Ekaros 4y ago
Somethings like control characters and null byte might cause issues. So likely better safe than sorry with those.
noufalibrahim 4y ago
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. 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 .˽...˽. 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. So yes, I think there might, atleast in theory, be good reasons to avoid certain characters in a password.
- chrismorgan 4y ago
  The space bar is just a big obvious form of audio attack that even humans can do with no tools or training, but really, if an attacker can hear you typing the password, it’s very heavily at risk. You can infer much more purely from the sound about the positioning of the hand and likely finger movements: in timing, most simply, but also in how sound bounces differently from different parts of the keyboard depending on what else is around (including the hands), and more. Practical attacks of this kind have been demonstrated. It is thus a security Best Practice for streamers and the likes to mute their microphones while typing passwords. Really, all senses leak information like this. Wifi signals are enough to see round corners and steal passwords. Even wearing a sleeveless shirt and having your upper arms visible to a camera leaks a little information from the small arm and theoretically even muscle movements.
- joshenders 4y ago
  There’s a paper about this and a demo site that can accurately derive your password based on a short training period and audio recording. They used distance between key presses and sounds of each key for their specialized acoustical analysis.
  - noufalibrahim 4y ago
wizofaus 4y ago
Allowing linefeeds/carriage returns/ASCII nulls seems like a bad idea. I have wanted to include backspace in a password though!
- adamrmcd 4y ago
  Unless you're manually injecting 0x08 into a database record, isn't it your keyboard that interprets your backspace into the UI layer. There's no way to type a backspace without literally pressing backspace :) Regarding the null, if it's C based, theoretically your password just stops there. All other chars after that would be ignored. Now I wonder, what would other non-C languages do if they see 0x00 in a string?
  - wizofaus 4y ago
    A password entry control doesn't have to interpret backspace the same way a regular text input control does (obviously meaning you'd need an alternative method of correcting typos). The 08 character can still be part of the control's "text" property that is ultimately hashed/stored etc. As for nulls, languages not based on C handle them fine but you'd have to be very careful they never got passed to an OS-level function, which nearly always treat them as terminators.
  - toast0 4y ago
    > There's no way to type a backspace without literally pressing backspace :) ctrl-H usually works.
can16358p 4y ago
Mandatory plug: https://xkcd.com/936/ https://xkcd.com/936/
- daneel_w 4y ago
  Ironically, that xkcd strip is crap advice. A dictionary attack breaks a mere four English words in half a jiffy. This approach should be enforced to a 9-10 word minimum.
  - BjoernKW 4y ago
    To offer a slightly more accurate measure than "half a jiffy", this article (published on May 9, 2022) lists the costs involved for different types of passwords and password lengths: https://support.1password.com/pbkdf2/ https://support.1password.com/pbkdf2/ Clocking in at a cracking cost of 79 million USD, for most intents and purposes, even a rather trivial 56-bit entropy password such as "align-caught-boycott-delete" (or "correct horse battery staple", for that matter) would be prohibitively expensive to break.
    - daneel_w 4y ago
      In the case of PBKDF2 it hinges on what PRF and how many rounds. As an example, WPA2 uses PBKDF2 with an HMAC and accompanying parameters to the tune of a single upper-tier consumer GPU being able to test just over a million passwords per second through hashcat. Realistically you will find the password long before you're close to the end of the key space.
  - ElectricalUnion 4y ago
    > A dictionary attack breaks a mere four English words in half a jiffy. What system allows you to try 2⁴³ passwords in half a jiffy?
    - daneel_w 4y ago
      I don't know what 2^43 would equate (four of the 1500 most common English words?), but an A100 GPU cluster at AWS would be a good starting point. I know, it's beyond the scope of you, me, and the neighbor kid. What I'm trying to get across is that short dictionary passwords have several innate vulnerabilities. They shouldn't be considered "long complicated passwords" until they're actually long.
deleted 4y ago
[deleted]
mstef 4y ago
let me quote NIST Special Publication 800-63B: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret > 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.
remorses 4y ago
Some Unicode characters can be represented in multiple ways, maybe it’s better to normalize password strings before storing or hashing them
jollyllama 4y ago
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.
phlo 4y ago
Let's start at the edgest of cases. 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. One step away from Emoji, Unicode also allows for other m̸̱̜̅ͅȋ̴̩̠̀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. 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. 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.
- delecti 4y ago
  > It is probably prudent for a system to disallow emoji passwords In addition, not all keyboard environments are capable of inputting the same set of emoji. A coworker once got locked out of his macbook because the UX when changing the password when already logged in allowed inputting emoji, but the OS login screen did not (could be misremembering some specifics, but the broad point remains). Which I suppose is really a subset of the sorts of issues around ç, ö and ø, but how it can happen even on the same system in different contexts.
- faebi 4y ago
  My favorite experience was with the backspace character. One of our cli tools accidentally saved them in a password store. The user can show his password but the console interpreted the backspace and therefore everything looked normal. That discovery was truly funny. Null byte characters create a funny user experience too. A user has an issue with an input, then I go and fix the problem by typing the same thing again and it works. These can end up in passwords too.
fallingknife 4y ago
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.
deleted 4y ago
[deleted]
josephcsible 4y ago
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. 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.
Someone 4y ago
As others said, it’s important that your users can enter their password on all devices they would want to use. 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) 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 ‘"’. 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.

38 points by andy_herbert 4y ago

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?

grishka 4y ago

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.

brendoncarroll 4y ago

I can think of a few reasons to exclude a character: - Requires quoting or escaping in the shell or some other programming environment - Hard to type on mobile keyboard. - Not in a given person's touch-typing repertoire. 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. 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.

blitzar 4y ago

If the character can not be hashed - outside of that, no reason at all. Although you should probably not allow "1234" as passwords or anything on the top 100 list for that matter.

hulitu 4y ago

Try to type a password with accents on an english keyboard

4oo4 4y ago

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. 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.

csydas 4y ago

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. 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. 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. 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.

dioxide 4y ago

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.

RicoElectrico 4y ago

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.

bombcar 4y ago
This is exactly it. Something somewhere broke on someone's password (think Bobby Tables) and so they forbid the character that done caused it.
tgv 4y ago
They just don't know how to get text unscrambled from a browser or an app's text box in server memory. That always makes me think they don't understand the design of what they're using, so they just forbid certain characters. When they forbid backslashes and quotes, it's even better: someone didn't know how to use query parameters or escape database values. It's a sign that their software is as secure as a "watch out for the dog" sign.

brodouevencode 4y ago

My credit card company does this, and it's infuriating

tiffanyh 4y ago

On mobile, keyboards typically auto capitalize the first letter of the first word. 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. So a UX pattern is to actually lowercase the first letter on the backend.

CJefferson 4y ago
Facebook actually do try flipping the capitalisation of your password (in case you have caps-lock on), and the capitalisation of the first letter (to cover this exact case): https://security.stackexchange.com/questions/68013/facebook-password-lowercase-and-uppercase https://security.stackexchange.com/questions/68013/facebook-... While this technically slightly lowers security (they are trying 4 passwords built from the one you typed in), I don't think that's significant, and I imagine it greatly improves user experience.
tgv 4y ago
I think browsers no longer do that when a field is labeled as a password. But there's always someone who still uses an Android 4 phone with Samsung Internet 0.37beta1.
- joshenders 4y ago
  For those living 10 years in the past, a degraded experience is probably par for the course and a fair forcing function to move on. You have draw the line somewhere and degrading the majority’s experience for the minority’s benefit is an unusual trade-off.
lolinder 4y ago
Both OSes have different keyboard configs for different field types, and at least on Android it most definitely does not capitalize the first letter on a password field. Maybe some third party keyboards do? Even so, my gut says that mangling passwords on the backend is a really bad solution that may come back to bite you in ways you don't expect.
joshenders 4y ago

remram 4y ago

You might want to run the password through Unicode-normalizing functions first (NFD or NFKD) but otherwise no. 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.

toast0 4y ago
> You might want to run the password through Unicode-normalizing functions first (NFD or NFKD) but otherwise no. If you do this, you should really save the version of the normalizing table you used, since they change over time.
- remram 4y ago
  Damn, I didn't even think about that. On the other hand I feel like if your password includes the kind of characters for which normalization rules are changing, you'll just have to reset it if it breaks. Tracking the version of the table is more than I'm willing to do.
avinassh 4y ago
> You might want to run the password through Unicode-normalizing functions first (NFD or NFKD) but otherwise no. what are these and why do you need to do it?
- remram 4y ago
  Some Unicode characters can be represented with different sequences of Unicode codepoints. For example é can be a single codepoint U+00E9 "latin small letter E with acute" or it can be the two codepoints U+0065 "latin small letter E" and U+0301 "combining acute accent". This is independent of the Unicode encoding, which turns those codepoints into bytes, for example using UTF-8 this gives C3A9 or 65CC81. Users don't really have control about what their keyboard/application is putting in the text field when they press the button, and obviously the hash of those is different so the password wouldn't match. Normalization is the process of turning the characters into its composed form (in my example "\u00E9") or the decomposed form ("\u0065\u0301"), so you can then compare your codepoints/bytes/hashes. https://en.wikipedia.org/wiki/Unicode_equivalence#Normalization https://en.wikipedia.org/wiki/Unicode_equivalence#Normalizat...

pestatije 4y ago

It forces the use of a new password specific to that site. Reusing passwords is considered bad for security.

joshenders 4y ago
Can you elaborate? It seems like it just enforces a specific type of password which is entirely reusable.
wizofaus 4y ago
Yes but that's a terrible way to enforce it. I've said here before I'd actually like the browser to forbid users from reusing passwords when signing up to new sites. I'm guessing there is actually a plugin that does it.

lexicality 4y ago

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". 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...

daneel_w 4y ago
> it's very important when you're storing passwords in plain text, so typically it's a sign the website is dangerously insecure ... This is a misconception. Password length is far more important than allowing a few "tricky" non-alphanumerics. It aids entropy, but it's not some security silver bullet. Also, if the web service you're using is storing undigested passwords then all bets are off.

prof-dr-ir 4y ago

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. 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. :)

Someone1234 4y ago

Typically, they're using legacy software to store the password itself (e.g. database, mainframe, etc). 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 (!). 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.

tzs 4y ago
> Typically, they're using legacy software to store the password itself (e.g. database, mainframe, etc) I've heard banks and other financial institutions use the "our ancient mainframe only allows 8 characters in account passwords" excuse or "our ancient mainframe database can only handle 8 characters in the password column", and find it extremely hard to believe. First of all, I find it hard to believe that each customer has a user account on the mainframe, and so the mainframe's restrictions on account passwords is irrelevant. Your banking account is going to be entirely something defined by the database. Second, I find it hard to believe that they are running their web server on their ancient mainframe OS. The web server is going to be running on something more modern. Users have to go through that to do online banking, and the account system on that can be totally separate from whatever account system is running on the backend banking system. Your user name (if their online banking uses something other than you account number) and you password for online banking should be entirely handled on the Unix or Unix-like or Windows Server that is running their web-facing stuff. The ancient mainframe stuff should never see it.
- Someone1234 4y ago
  > I find it hard to believe that each customer has a user account on the mainframe Why? Do you actually have any experience in this area? I do, and I can tell you, they do exactly that. Then multiple systems integrate with that mainframe, often using the user account as the unique identifier for the entire organization. Migrations are an absolute nightmare. > Users have to go through that to do online banking, and the account system on that can be totally separate from whatever account system is running on the backend banking system. It can be, but it isn't. Thus, the problem. Honestly this type of "hardly believe" take is what every new employee right out of college (or myself 15 years ago) when they come up with ten thousand "simple" ideas for improvement without any organization, political, or system understanding. Then they act confused when their ideas aren't instantly implemented, because they don't even understand what it is they're proposing or why it is complicated. Banks have been trying to get off of mainframes for 30-years or more at this point, spent tens of millions of dollars, but had someone just told them to "run a web server in front of it" this could all have been avoided.

RedNifre 4y ago

I think there was a story about somebody locking himself out of macOS, because he couldn't enter Emoji on the login screen. Also, since my password manager types letters one by one, I wouldn't use tabs or line feeds. Maybe don't use grapheme clusters that have multiple valid encodings and make up for it by using a longer password instead?

GnarfGnarf 4y ago

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. Possibly they're preparing for password entry on more ubiquitous devices with limited keyboards? (ATMs, credit card keypads).

_dain_ 4y ago

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). 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.

Ekaros 4y ago

Somethings like control characters and null byte might cause issues. So likely better safe than sorry with those.

noufalibrahim 4y ago

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. 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 .˽...˽. 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. So yes, I think there might, atleast in theory, be good reasons to avoid certain characters in a password.

chrismorgan 4y ago
The space bar is just a big obvious form of audio attack that even humans can do with no tools or training, but really, if an attacker can hear you typing the password, it’s very heavily at risk. You can infer much more purely from the sound about the positioning of the hand and likely finger movements: in timing, most simply, but also in how sound bounces differently from different parts of the keyboard depending on what else is around (including the hands), and more. Practical attacks of this kind have been demonstrated. It is thus a security Best Practice for streamers and the likes to mute their microphones while typing passwords. Really, all senses leak information like this. Wifi signals are enough to see round corners and steal passwords. Even wearing a sleeveless shirt and having your upper arms visible to a camera leaks a little information from the small arm and theoretically even muscle movements.
joshenders 4y ago
There’s a paper about this and a demo site that can accurately derive your password based on a short training period and audio recording. They used distance between key presses and sounds of each key for their specialized acoustical analysis.
- noufalibrahim 4y ago

wizofaus 4y ago

Allowing linefeeds/carriage returns/ASCII nulls seems like a bad idea. I have wanted to include backspace in a password though!

adamrmcd 4y ago
Unless you're manually injecting 0x08 into a database record, isn't it your keyboard that interprets your backspace into the UI layer. There's no way to type a backspace without literally pressing backspace :) Regarding the null, if it's C based, theoretically your password just stops there. All other chars after that would be ignored. Now I wonder, what would other non-C languages do if they see 0x00 in a string?
- wizofaus 4y ago
  A password entry control doesn't have to interpret backspace the same way a regular text input control does (obviously meaning you'd need an alternative method of correcting typos). The 08 character can still be part of the control's "text" property that is ultimately hashed/stored etc. As for nulls, languages not based on C handle them fine but you'd have to be very careful they never got passed to an OS-level function, which nearly always treat them as terminators.
- toast0 4y ago
  > There's no way to type a backspace without literally pressing backspace :) ctrl-H usually works.

can16358p 4y ago

Mandatory plug: https://xkcd.com/936/ https://xkcd.com/936/

daneel_w 4y ago
Ironically, that xkcd strip is crap advice. A dictionary attack breaks a mere four English words in half a jiffy. This approach should be enforced to a 9-10 word minimum.
- BjoernKW 4y ago
  To offer a slightly more accurate measure than "half a jiffy", this article (published on May 9, 2022) lists the costs involved for different types of passwords and password lengths: https://support.1password.com/pbkdf2/ https://support.1password.com/pbkdf2/ Clocking in at a cracking cost of 79 million USD, for most intents and purposes, even a rather trivial 56-bit entropy password such as "align-caught-boycott-delete" (or "correct horse battery staple", for that matter) would be prohibitively expensive to break.
  - daneel_w 4y ago
    In the case of PBKDF2 it hinges on what PRF and how many rounds. As an example, WPA2 uses PBKDF2 with an HMAC and accompanying parameters to the tune of a single upper-tier consumer GPU being able to test just over a million passwords per second through hashcat. Realistically you will find the password long before you're close to the end of the key space.
- ElectricalUnion 4y ago
  > A dictionary attack breaks a mere four English words in half a jiffy. What system allows you to try 2⁴³ passwords in half a jiffy?
  - daneel_w 4y ago
    I don't know what 2^43 would equate (four of the 1500 most common English words?), but an A100 GPU cluster at AWS would be a good starting point. I know, it's beyond the scope of you, me, and the neighbor kid. What I'm trying to get across is that short dictionary passwords have several innate vulnerabilities. They shouldn't be considered "long complicated passwords" until they're actually long.

deleted 4y ago

[deleted]

mstef 4y ago

let me quote NIST Special Publication 800-63B: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret > 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.

remorses 4y ago

Some Unicode characters can be represented in multiple ways, maybe it’s better to normalize password strings before storing or hashing them

jollyllama 4y ago

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.

phlo 4y ago

Let's start at the edgest of cases. 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. One step away from Emoji, Unicode also allows for other m̸̱̜̅ͅȋ̴̩̠̀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. 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. 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.

delecti 4y ago
> It is probably prudent for a system to disallow emoji passwords In addition, not all keyboard environments are capable of inputting the same set of emoji. A coworker once got locked out of his macbook because the UX when changing the password when already logged in allowed inputting emoji, but the OS login screen did not (could be misremembering some specifics, but the broad point remains). Which I suppose is really a subset of the sorts of issues around ç, ö and ø, but how it can happen even on the same system in different contexts.
faebi 4y ago
My favorite experience was with the backspace character. One of our cli tools accidentally saved them in a password store. The user can show his password but the console interpreted the backspace and therefore everything looked normal. That discovery was truly funny. Null byte characters create a funny user experience too. A user has an issue with an input, then I go and fix the problem by typing the same thing again and it works. These can end up in passwords too.

fallingknife 4y ago

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.

deleted 4y ago

[deleted]

josephcsible 4y ago

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. 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.

Someone 4y ago

As others said, it’s important that your users can enter their password on all devices they would want to use. 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) 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 ‘"’. 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.