Ask HN: Why are username and password fields limited to certain characters? | Hacker News Reader

Ask HN: Why are username and password fields limited to certain characters?

12 pointsm33k4420 comments

This could be a noob question as I am not a web developer, but why limit the username and password fields to certain characters?

View on HN

Because sanitization is not easy. You can visually spoof user names with Unicode, e.g. this Unicode: "аdmіn", is not really same as this ASCII: "admin" [0]. Both would create two separate accounts without input limitation. There is more variety with available alphabets [1].

[0] https://onlineunicodetools.com/spoof-unicode-text?input=Noth...

[1] https://qaz.wtf/u/convert.cgi?text=admin

Optimistic wishful thinking version: It's cargo cult cultural heritage from a time before proper input sanitation and password hashing. (bad characters like " would make either the receiving backend code bork, cause an SQL escape or be inserted as-is into a database field not supporting the character).

More likely: It's not cargo-cult cultural heritage and stuff is still that bad in some places.

As for hashing bruteforce attacks: no problem, do an initial hashing round on the client before even sending it to the backend.

Some characters may also be nicer to type since they're present (and perhaps even in the same location) on many keyboard layouts. People could in principle cause themselves problems with logging in by having their usernames or passwords include characters that are hard or impossible to directly enter on another keyboard layout.

I'm not sure that would be an actual reason why some designers have decided to limit the set of allowed characters, and your guesses may be better. But it could be something to consider.

My email password used to contain a pattern of symbols that I knew by pattern in QWERTY. I ended up at a cyber cafe in Europe locked out of my email because I didn’t remember the actual symbols.

Fun story: On Mac, you could also set your password to contain emoji that you couldn't manage type on the login screen.

https://apple.stackexchange.com/questions/202143/i-included-...

Client hashing limits the variety of hash inputs on the server side, so it is actually worse for security. Think of it this way: hashes of a certain kind follow a pattern for which characters are used and the length and they cannot be salted on the client (because then you'd need to send the salt to the client, making it useless) so it is effectively like having a password restriction like that all passwords must be exactly 64 chars long and only use hex chars.

Hash once (on the server) and treat passwords as a binary blob (in other words no validation) until they are hashed. Have some sensible upper bound on how big the password blob can be, but make it larger than any reasonable password manager would create (like 100kb).

There are a few flaws in your argument, please don't take this as an insult. Client hashing does not limit the varity of hash inputs on the server side. You should absolutely send salt to the client, even on (especially on) a plaintext connection. There is no law against doing key stretching or using a longer hash on the client.

I'm not sure what your reasoning is for sending salt to the client should be useless.

Are you arguing somehow that the salt must be private (wrong) and is compromises security in the client ? Think about that for a second, if the client has their traffic sniffed and decrypted, then sending the plaintext password back to the server (your suggested solution) is just as broken.

Client side hashing+salting is a compliment to server-side hasing+salting, not a replacement.

Simplified: The server stores salt and saltedHashFromPassword ( hash(salt+pass) ) On login request server generates salt' and sends salt and salt'.

client sends back hash(salt' + hash(salt+passw)) server compares hash from client to hash(salt' + saltedHashFromPassword)

Now, unless you've owned the client, you'll only ever learn their salt, which is not important, and their salt' which changes with each login request.. the resulting hash cannot be played back as the salt' is invalidated after a login attempt. Assuming a secure hashing algorithm, this even works over plaintext connections.

As to the 64 chars, true, if you're doing no keystreching (which can be plopped over the example above with no problem), however, I assume you're talking about situations where nobody stole the database (the security implications of clinet side hashing are not relevant in that case), but you mean to "just generate that number between 0 and 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff and send that directly to the server".. Well, nope, because you cannot just do 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff requests as the valid hash changes with each attempt to login, I can't even the maths here, 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff rasied to the 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffth power attempts might still not get you in, the target is moving and there's no guarantee that you will ever hit it.

Long passwords can cause a DDOS attack as they need to be hashed. Longer the password, longer the hashing takes. Django had to patch this back in 2013: https://github.com/django/django/commit/5ecc0f828ebe270cfc92...

The patch was reverted later:

https://github.com/django/django/pull/1653

Certain systems were built by certain very stupid people, and not only do not hash the passwords before inserting or checking them against the database, but additionally neither use the built-in parameter quoting system nor manually quote the password when it goes into the query. Fortunately they're not quite dumb enough to allow the old " OR "" = " attack, and so make sure you don't have any SQL characters like " or ; in your password.

Sometimes the backing database is a legacy system that can only accept certain encodings or symbols.

Not only this but I've seen databases that accept emojis but break them during some form of migration. It's fine to break some kind of description, but not username and password.

This is why almost every bank website has this limitation today.

Why would the password’s original encoding be stored in the database instead of a hash?

A blunt instrument against SQL injection attack: https://owasp.org/www-community/attacks/SQL_Injection

So I can't set my username to "თ̶̪̫͑ა̷̘̒͝ვ̶̪̀̃ა̸̍͜დ̷̄ͅ ̴̢̟͠ტ̶̻̀̎კ̷̡̂ი̴͇͓́̍ვ̶̻̐ი̶̹͍͒ლ̷̙͘ი̵̪̠͆". For extra fun, remember that there are many forms of whitespace characters.

Usernames should probably be limited to a subset of printable ASCII.

However, for passwords, you should allow any sequence of bytes (as much as the system can support it, which it should allow any sequence since they should be hashed anyways), and the maximum length should be sufficiently long (and don't truncate passwords either).

Depends what you’re doing with the username.

Sometimes it’s just being able to be standards compliant in future:

POSIX stipulates that a dot should separate the user with the group (so jan.harasym is technically an illegal unix user name, and as such might break non-gnu `chown`)

If your username is for a comprehensive suite like Google’s gsuite then having an “@“ or “%” would make your email address invalid.

There could be encoding issues too, but I think the majority of new systems use UTF-8.

I haven’t seen a _real_ encoding issue in about 4 years.

If you're displaying username (like on NewsHacker) then maybe you don't want to allow people to use fancy weird characters that are untypable

For usernames it's reasonable. People identify other people based on usernames, so allowing unicode control charachters or zero-width spaces would not be good. If your username is only for login then it should be fine to allow anything.

For passwords it's just bad practice. Allow everything, and allow it to be very long.

Reply on news.ycombinator.com