Live data from Hacker News

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

news.ycombinator.com

41–50 of 79 posts

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

#41
post #31

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 d…

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

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

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

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

#44
post #31

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 d…

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.

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

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

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

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.

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

#46
post #31

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 d…

I don’t think it’s prudent for a system to disallow emoji passwords. Or to restrict various characters. I say: let the user do what they want to do; on their own heads be it if they do something that doesn’t work for them in all circumstances, and the end result is practically not much different from forgetting a password, which is normal.

In general, passwords are not treated as essential for access, and there will be recovery techniques, and the number of password resets or whatever required because they can’t type such-and-such a character any more or on this new device will be a minuscule fraction of the total. Resetting passwords and other forms of lost account access is typically not an exceptional path. From what I’ve seen, for business-to-customer businesses that don’t have some form of self-serve account recovery, “I’ve lost access to my account” will routinely be half your ticket volume.

In those fairly uncommon situations where passwords are essential for access (e.g. where it’s an encryption key), well, it’s still up to the user, and the user is somewhat more likely to be aware of any potential hazards in such fanciness.

Overall, I say: stop trying to be clever; accept what is set before you without asking questions on the grounds of compatibility. Let the user do what they try to do.

Maybe normalise Unicode; it’s a harmless thing to do and has the potential to improve compatibility slightly on very unusual input devices. (I don’t think I’d bother, myself.) But beyond that, I’m not sold on the arguments for restricting possibilities.

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

#47
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”?

I'm not sure why people should design for the expert user in cases like this?

I don't understand why this would cause an expert user trouble (it's the loss of a single bit of password security, which shouldn't matter if your password is even reasonably decent).

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

#48
post #28

Earlier quoted context omitted.

(One of) my pet peeves is requiring a certain format for passwords but then not telling you at the password prompt. I mean, you're not supposed to write down passwords, but with all the various restrictions you can't even use a consistent convention so you can actually remember them all.

> I mean, you're not supposed to write down passwords, but with all the various restrictions you can't even use a consistent convention so you can actually remember them all. You're supposed to use a password manager. Preferably with a passphrase and a second factor like a keyfile or hardware token.

While password managers are great, there are some cases where I prefer to memorize the password.

That is because I want to be always able to easily access these accounts even when traveling or losing access to my technological devices. Though sadly these days things like 2FA make my life much harder in that regard.

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

#49

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

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?

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

#50
post #28

Earlier quoted context omitted.

(One of) my pet peeves is requiring a certain format for passwords but then not telling you at the password prompt. I mean, you're not supposed to write down passwords, but with all the various restrictions you can't even use a consistent convention so you can actually remember them all.

> I mean, you're not supposed to write down passwords, but with all the various restrictions you can't even use a consistent convention so you can actually remember them all. You're supposed to use a password manager. Preferably with a passphrase and a second factor like a keyfile or hardware token.

Are you 'supposed to' or is that just the least worst option?

There are fairly limited scenarios when a password manager is better than a plain text document. And if it's online to actually share passwords between devices it's strictly worse.

Post reply on HN