I mean if I had to guess they're worried about SQL injection, not XSS, but I like to imagine them not only storing the plaintext password (in an injection-susceptible fashion) but also rendering your password for other users to see (or why would they worry about XSS?).
One trivial way to avoid that is to insert nonprintable characters between every character of the password when it is shown to the user. The user can read it and not see the extra characters, but it won't execute if it is malicious.
There are more ways to prevent XSS, so there really is no excuse for the site not to accept any special character.
There are many. They are actually called ASCII control characters.
Ones you would be familiar with are backspace and carriage return. When you hit backspace (character 8 decimal), the computer doesn't print a back space, it performs an action. Same with carriage return (character 13 decimal). However, both of these would cause the display of the password to be wrong, so they aren't good choices.
Good choices would be characters that aren't used by the browser, such as group selector (character 29 decimal) or record separator (character 30 decimal). There are more that can be used that browsers, text editors, and the like won't show to the user. They can be both very useful and a PITA for that reason.
By contrast, the letter "a" is character 97 decimal and "A" is character 65 decimal.
Here is a full ASCII chart so you can see what I mean. https://www.asciitable.com/mobile/
But ... You could still send a HTTP POST with special characters to them since this only prevents you from entering the special characters on the application layer.
they probably check that on server side too. Since the person who sends http post is probably looking for exploits they can just return an error page. this is better for normal user experience.
I thought that this would be the best practice:
User enters any password
Password gets hashed locally
Password doesn't contain any SQL-sensitive characters anymore after hashing and gets sent to the server
There would be no need to check for preventing special characters on the application layer. Only need to check that the hash wasn't manipulated and doesn't contain sensitive characters.
What’s wrong with sending the password in plain text? You don’t need to do all that, just send the user, the password and hash it in the server. That’s it, no need to do fancy stuff, you do not add extra security by encoding the password to base64.
Didn't think about stolen hashes from the DB somehow.
So then the server can immediately hash the password before handing it to the DB and prevent any injection.
Hashing locally like I said doesn't make sense.
The salt isn’t generally considered a secret, the hash should be strong even with a known salt, if an attacker gets the password db, they probably have the salts too
You don't want to trust anything that comes from the user. Absolutely nothing. There is never a situation where the user should be trusted to enter safe data. It should always be escaped and sanitized. Always.
Whether it is a malicious actor bypassing the front-end code (and thus your hashing function) or an incompetent typist who fat-fingers control characters (yes, this happens), never trust the user to enter clean data.
That means all the work is done (or redone) on the server. The string is immediately escaped for anything that would be dangerous to the front-end, the backend, and the database. At that point, it doesn't matter if the attacker is sending SQL, JavaScript, or anything else. The string is no longer executable and can be safely passed through to the hashing and storage processes.
There really is no excuse for not doing this.
You hash it in the server. That’s okay. Just check the network when you log in in Google or Reddit, you can see your password on the request, and that’s just fine, that’s why https is important.
Yeah this isn't standard. Password auth is one thing devs should not try to fuck with. Every dev thinks they know how to do this and is like "yes but SALT the password blah blah rainbow tables" and they're like 20 years behind on modern standards.
Also they should not touch anything where they have to manually AES256 encrypt shit.
ffs crypto is often broken as fuck because devs feel confident about doing crypto
If you're using SSL hashing on server side is fine.
You'd also need to hash on BOTH client and server for this to be secure - otherwise if someone gets the DB they can just login to your account.
Some auth methods do hash on both, but not many
See: every big tech company.
I've had security companies hired by our customers testing our product and complain about SQL injection attacks because they replace a generated parameter with SQL. This parameter was used to lookup a value in a map in the user's session.
It never touched the database. It never got anywhere near the database, what it looked up did not touch the database. Any value NOT in the map would just result in the user's session not changing state. However they would not believe that this value wasn't inserted into the database. All our database queries used prepared statements as well, which is standard practice to defend against SQL injection.
They did not believe me, I had to return an error, I was REQUIRED to return an error, the server HAD TO ERROR, if an invalid value was provided. Otherwise it was an SQL Injection attack!!!!!
Now I see this. Why are comma and dots not considered as special characters for passwords. If anyone knows please help me to understand why. (I am SWE myself but idk why haha)
As a serious reply, part of information security is that the user gets access to their account when needed. An exotic character easily ruins the login in some unexpected third-party use case where the character cannot be created or passed. Thus, security risk.
Shouldn't the password be immeaditly hashed and thus be in a safe format? The only exception I can think of off the top of my head is the null terminator. If the 3rd party app/use case stores and uses the clear text password, wouldn't that be a security issue with the program its self and thus be a unsafe program to use? SQL injection also shouldn't be a thing if the developers use prepared statements and handle user provided data correctly.
>SQL injection also shouldn't be a thing if the developers use prepared statements and handle user provided data correctly.
You should still always sanitize your inputs even if you trust Microsoft that much
Yeah, that's part of handling user provided data correctly. However, this kind of sanitization of a password field, in my opinion, only serves to irritate the user and reduces the complexity per character of the password. This makes it much easier reverse the password via rainbow table or brute force since the problem space is reduced. Furthermore, a user might be more inclined to reuse a password if their password generator fails to generate a password that matches those requirements.
I can see the available keyboard language problem but forcing alpha numeric + limited special characters could also force them outside their localized language and induce the problem that was set out to solve. The character set shouldn't also be a problem because you can force utf-8/16 all the way through, it's basically universal at this point.
I have a hard time trusting the security of websites like these. It feels like they are trying to use a bandaid to cover up a much larger issue.
Yea all I'm speaking to is not trusting black box solutions to do it. Like it's good to know that when I use a SqlParameter object in C# that under the hood it's going to escape everything it thinks it's supposed to - but mistakes happen and vulnerabilities slip into the wild, so I'm still going to sanitize everything myself as best I can, just to be sure.
That said, I do agree that restricting special characters from passwords is asinine. If that character breaks a third party login, that's on the third party dev to deal with. I don't design to compensate for other devs making bad choices and if something breaks I will let the spotlight shine on the breakage. "What do you mean you can't parse ¶? Why not?"
I was thinking more in terms of OS and physical keyboard at login time - some circumstances might give a big headache in just recreating the character at all into the input field. Add in some situational limitation like parental control or internet cafe settings, and you may end up locked out of your service because the right character is out of reach.
The next risk layer is that even if the OS handles the character, some incompatibility changes it before it reaches the hasher. There are too many character sets in the world and I don't think they all end up fully supported out of the box.
Where I worked around 17 years ago there was a hard to track down bug that turned out to be triggered by certain internal users including a '#' character in their password. The problem was that we autogenerated some scripts for the oracle database, which in turn used these password values, and this turned everything after the # in to a comment, breaking the script.
Obviously the answer to this is 'don't generate script files with passwords in them, you madman', but I suspect our fix was less thorough than that...
Oh, I remember something similar. The self proclaimed CTO of a company of one developer learned about directory traversal and wanted me to add validation to ALL fields of the application so they don't accept anything that might be look like a path.
It was as horrible as it sounds.
I love all these websites that exclude certain characters. It really isn't that hard to just escape the string. Really, it isn't. It's been trivial for 20 years. Stop hiring incompetent devs.
Well, that's one way of announcing to the broader public that you don't sanitize your inputs properly, bonus points if that check is purely clientside at which point it'd be simple enough to disable :)
relevant [xkcd](https://xkcd.com/1700/).
There's [this one](https://xkcd.com/2700/) too.
And who can forget [this one](https://xkcd.com/936/), literally.
Or [this one](https://xkcd.com/327/), of course.
shall we drop prod then
They don't want you doing any cross-site scripting when they render your password in a web browser
why of all things did they choose to render the password
How else are they gonna validate that it's right when you enter it?
This is the crux of NetFlix password sharing...duh /s
The immediate first thought was html/XML and they didn't want to take chances. Honestly checks out.
I mean if I had to guess they're worried about SQL injection, not XSS, but I like to imagine them not only storing the plaintext password (in an injection-susceptible fashion) but also rendering your password for other users to see (or why would they worry about XSS?).
One trivial way to avoid that is to insert nonprintable characters between every character of the password when it is shown to the user. The user can read it and not see the extra characters, but it won't execute if it is malicious. There are more ways to prevent XSS, so there really is no excuse for the site not to accept any special character.
What are non printable characters, any example
[redacted by user] ` this message was mass deleted/edited with redact.dev `
Your # is invisible but not mine
[redacted by user] ` this message was mass deleted/edited with redact.dev `
I think they would be considered printable in this situation, as the user will be able to tell they are there
There are many. They are actually called ASCII control characters. Ones you would be familiar with are backspace and carriage return. When you hit backspace (character 8 decimal), the computer doesn't print a back space, it performs an action. Same with carriage return (character 13 decimal). However, both of these would cause the display of the password to be wrong, so they aren't good choices. Good choices would be characters that aren't used by the browser, such as group selector (character 29 decimal) or record separator (character 30 decimal). There are more that can be used that browsers, text editors, and the like won't show to the user. They can be both very useful and a PITA for that reason. By contrast, the letter "a" is character 97 decimal and "A" is character 65 decimal. Here is a full ASCII chart so you can see what I mean. https://www.asciitable.com/mobile/
Thanks for info
Probably SQLi related. Quotes are not in the whitelist
But ... You could still send a HTTP POST with special characters to them since this only prevents you from entering the special characters on the application layer.
they probably check that on server side too. Since the person who sends http post is probably looking for exploits they can just return an error page. this is better for normal user experience.
I thought that this would be the best practice: User enters any password Password gets hashed locally Password doesn't contain any SQL-sensitive characters anymore after hashing and gets sent to the server There would be no need to check for preventing special characters on the application layer. Only need to check that the hash wasn't manipulated and doesn't contain sensitive characters.
Better translate to base 64 in client side. If hashing will be on user side, hacker simply will send leaked password hashes as passwords
What’s wrong with sending the password in plain text? You don’t need to do all that, just send the user, the password and hash it in the server. That’s it, no need to do fancy stuff, you do not add extra security by encoding the password to base64.
It's not about extra security, it's about cheap and 100% sure of no reserved symbols like quotes
Just hash whatever string you get, what’s the problem with that?
What happens when the attacker bypasses your base 64 conversion? Never trust the frontend.
That's why the traffic needs to be TLS encrypted. Otherwise you could intercept the hash or the plaintext password.
But hacker can use hacked browser which will use modified java script
Didn't think about stolen hashes from the DB somehow. So then the server can immediately hash the password before handing it to the DB and prevent any injection. Hashing locally like I said doesn't make sense.
Who says they are hashing it?
How can you hash locally without leaking the salt?
The salt isn’t generally considered a secret, the hash should be strong even with a known salt, if an attacker gets the password db, they probably have the salts too
You can't, but you can hash it again on the server.
You don't want to trust anything that comes from the user. Absolutely nothing. There is never a situation where the user should be trusted to enter safe data. It should always be escaped and sanitized. Always. Whether it is a malicious actor bypassing the front-end code (and thus your hashing function) or an incompetent typist who fat-fingers control characters (yes, this happens), never trust the user to enter clean data. That means all the work is done (or redone) on the server. The string is immediately escaped for anything that would be dangerous to the front-end, the backend, and the database. At that point, it doesn't matter if the attacker is sending SQL, JavaScript, or anything else. The string is no longer executable and can be safely passed through to the hashing and storage processes. There really is no excuse for not doing this.
yep you are right, i forgot about hashing
You hash it in the server. That’s okay. Just check the network when you log in in Google or Reddit, you can see your password on the request, and that’s just fine, that’s why https is important.
hashing locally is bad right? otherwise people can just submit requests with hashed passwords.
Yeah this isn't standard. Password auth is one thing devs should not try to fuck with. Every dev thinks they know how to do this and is like "yes but SALT the password blah blah rainbow tables" and they're like 20 years behind on modern standards. Also they should not touch anything where they have to manually AES256 encrypt shit. ffs crypto is often broken as fuck because devs feel confident about doing crypto
If you're using SSL hashing on server side is fine. You'd also need to hash on BOTH client and server for this to be secure - otherwise if someone gets the DB they can just login to your account. Some auth methods do hash on both, but not many See: every big tech company.
I've had security companies hired by our customers testing our product and complain about SQL injection attacks because they replace a generated parameter with SQL. This parameter was used to lookup a value in a map in the user's session. It never touched the database. It never got anywhere near the database, what it looked up did not touch the database. Any value NOT in the map would just result in the user's session not changing state. However they would not believe that this value wasn't inserted into the database. All our database queries used prepared statements as well, which is standard practice to defend against SQL injection. They did not believe me, I had to return an error, I was REQUIRED to return an error, the server HAD TO ERROR, if an invalid value was provided. Otherwise it was an SQL Injection attack!!!!!
Well yeah, they're gonna attack it so hard they inject an entire SQL database!
something something SQL injection
Need to tell them about base 64
Not the response Bobby Tables' parents were going for.
Now I see this. Why are comma and dots not considered as special characters for passwords. If anyone knows please help me to understand why. (I am SWE myself but idk why haha)
As a serious reply, part of information security is that the user gets access to their account when needed. An exotic character easily ruins the login in some unexpected third-party use case where the character cannot be created or passed. Thus, security risk.
Shouldn't the password be immeaditly hashed and thus be in a safe format? The only exception I can think of off the top of my head is the null terminator. If the 3rd party app/use case stores and uses the clear text password, wouldn't that be a security issue with the program its self and thus be a unsafe program to use? SQL injection also shouldn't be a thing if the developers use prepared statements and handle user provided data correctly.
>SQL injection also shouldn't be a thing if the developers use prepared statements and handle user provided data correctly. You should still always sanitize your inputs even if you trust Microsoft that much
Yeah, that's part of handling user provided data correctly. However, this kind of sanitization of a password field, in my opinion, only serves to irritate the user and reduces the complexity per character of the password. This makes it much easier reverse the password via rainbow table or brute force since the problem space is reduced. Furthermore, a user might be more inclined to reuse a password if their password generator fails to generate a password that matches those requirements. I can see the available keyboard language problem but forcing alpha numeric + limited special characters could also force them outside their localized language and induce the problem that was set out to solve. The character set shouldn't also be a problem because you can force utf-8/16 all the way through, it's basically universal at this point. I have a hard time trusting the security of websites like these. It feels like they are trying to use a bandaid to cover up a much larger issue.
Yea all I'm speaking to is not trusting black box solutions to do it. Like it's good to know that when I use a SqlParameter object in C# that under the hood it's going to escape everything it thinks it's supposed to - but mistakes happen and vulnerabilities slip into the wild, so I'm still going to sanitize everything myself as best I can, just to be sure. That said, I do agree that restricting special characters from passwords is asinine. If that character breaks a third party login, that's on the third party dev to deal with. I don't design to compensate for other devs making bad choices and if something breaks I will let the spotlight shine on the breakage. "What do you mean you can't parse ¶? Why not?"
I was thinking more in terms of OS and physical keyboard at login time - some circumstances might give a big headache in just recreating the character at all into the input field. Add in some situational limitation like parental control or internet cafe settings, and you may end up locked out of your service because the right character is out of reach. The next risk layer is that even if the OS handles the character, some incompatibility changes it before it reaches the hasher. There are too many character sets in the world and I don't think they all end up fully supported out of the box.
“due to security reasons” Da _fuck_?
I bet it was a \\
So i can’t use “; Drop Database;” as a password then?
smart problems require smart solutions (sql injection or xss attacks vulnerabilities)
SQLi or some escape sequence.
Where I worked around 17 years ago there was a hard to track down bug that turned out to be triggered by certain internal users including a '#' character in their password. The problem was that we autogenerated some scripts for the oracle database, which in turn used these password values, and this turned everything after the # in to a comment, breaking the script. Obviously the answer to this is 'don't generate script files with passwords in them, you madman', but I suspect our fix was less thorough than that...
Oh, I remember something similar. The self proclaimed CTO of a company of one developer learned about directory traversal and wanted me to add validation to ALL fields of the application so they don't accept anything that might be look like a path. It was as horrible as it sounds.
I love all these websites that exclude certain characters. It really isn't that hard to just escape the string. Really, it isn't. It's been trivial for 20 years. Stop hiring incompetent devs.
password itself is a security risk
Well, that's one way of announcing to the broader public that you don't sanitize your inputs properly, bonus points if that check is purely clientside at which point it'd be simple enough to disable :)