8 ms·

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

12 points by m33k44 5y ago

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

schappim 5y ago
Sometimes the backing database is a legacy system that can only accept certain encodings or symbols.
- bob1029 5y ago
  This is why almost every bank website has this limitation today.
- muzani 5y ago
  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.
- spenczar5 5y ago
  Why would the password’s original encoding be stored in the database instead of a hash?
marklit 5y ago
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/5ecc0f828ebe270cfc92a0a2bfb4268800907904 https://github.com/django/django/commit/5ecc0f828ebe270cfc92...
- joshtam 5y ago
  Could you please elaborate on why the length is worse? This is interesting!
- jwilk 5y ago
  The patch was reverted later: https://github.com/django/django/pull/1653 https://github.com/django/django/pull/1653
pie_flavor 5y ago
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.
dusted 5y ago
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.
- Delk 5y ago
  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.
  - KMnO4 5y ago
    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.
  - ThePadawan 5y ago
    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-emoji-in-my-password-and-now-i-cant-log-in-to-my-account-on-yosemite https://apple.stackexchange.com/questions/202143/i-included-...
- SahAssar 5y ago
  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).
dijit 5y ago
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.
tester34 5y ago
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
SideburnsOfDoom 5y ago
A blunt instrument against SQL injection attack: https://owasp.org/www-community/attacks/SQL_Injection https://owasp.org/www-community/attacks/SQL_Injection
muzani 5y ago
So I can't set my username to "თ̶̪̫͑ა̷̘̒͝ვ̶̪̀̃ა̸̍͜დ̷̄ͅ ̴̢̟͠ტ̶̻̀̎კ̷̡̂ი̴͇͓́̍ვ̶̻̐ი̶̹͍͒ლ̷̙͘ი̵̪̠͆". For extra fun, remember that there are many forms of whitespace characters.
SahAssar 5y ago
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.
imhoguy 5y ago
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=Nothing%20happens%20unless%20first%20we%20dream.&insert-zero-width-spaces=false&spoof-punctuation=false&spoof-spaces=false&preview-spoof=false https://onlineunicodetools.com/spoof-unicode-text?input=Noth... [1] https://qaz.wtf/u/convert.cgi?text=admin https://qaz.wtf/u/convert.cgi?text=admin
zzo38computer 5y ago
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).

12 points by m33k44 5y ago

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

schappim 5y ago

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

bob1029 5y ago
This is why almost every bank website has this limitation today.
muzani 5y ago
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.
spenczar5 5y ago
Why would the password’s original encoding be stored in the database instead of a hash?

marklit 5y ago

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/5ecc0f828ebe270cfc92a0a2bfb4268800907904 https://github.com/django/django/commit/5ecc0f828ebe270cfc92...

joshtam 5y ago
Could you please elaborate on why the length is worse? This is interesting!
jwilk 5y ago
The patch was reverted later: https://github.com/django/django/pull/1653 https://github.com/django/django/pull/1653

pie_flavor 5y ago

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.

dusted 5y ago

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.

Delk 5y ago
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.
- KMnO4 5y ago
  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.
- ThePadawan 5y ago
  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-emoji-in-my-password-and-now-i-cant-log-in-to-my-account-on-yosemite https://apple.stackexchange.com/questions/202143/i-included-...
SahAssar 5y ago
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).

dijit 5y ago

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.

tester34 5y ago

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

SideburnsOfDoom 5y ago

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

muzani 5y ago

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

SahAssar 5y ago

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.

imhoguy 5y ago

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=Nothing%20happens%20unless%20first%20we%20dream.&insert-zero-width-spaces=false&spoof-punctuation=false&spoof-spaces=false&preview-spoof=false https://onlineunicodetools.com/spoof-unicode-text?input=Noth... [1] https://qaz.wtf/u/convert.cgi?text=admin https://qaz.wtf/u/convert.cgi?text=admin

zzo38computer 5y ago

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