Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 79 posts

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

#11

Post by Someone1234 »

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.

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

#12

Post by RedNifre »

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?

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

#13

Post by tgv »

RicoElectrico wrote: post #2

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.

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.

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

#14

Post by tgv »

tiffanyh wrote: post #9

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.

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.

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

#15

Post by lolinder »

tiffanyh wrote: post #9

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.

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.

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

#16

Post by GnarfGnarf »

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

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

#17

Post by _dain_ »

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.

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

#18

Post by joshenders »

tiffanyh wrote: post #9

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.

As far as I can tell, this hasn’t been an issue for over 10 years—at least for Apple devices?

Whatever happened to, “Design for the expert user”?

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

#20

Post by joshenders »

tgv wrote: post #14
tiffanyh wrote: post #9

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.

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.

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.

Post reply on HN