3 ms·

Optimistic wishful thinking version: It's cargo cult cultural heritage from a time before proper input sanitation and password hashing. (bad characters like " w

by 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).
- dusted 5y ago
  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.

by dusted 5y ago

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

dusted 5y ago
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.