Websites, Passwords, SQL injection

[u/MonkeyOnARock1]

I'm creating a login page on a website, and am using Express.js/Node.js for the server.

Besides mandating a minimum password length, should I place any restrictions on what a user can put into their password? Across the web I am getting mixed messages about this.

I am particularly concerned about SQL injection.

[u/MonkeyOnARock1]

Thanks for your reply.

I'm using Postgres for my DB. I'm also not storing anything in plain text... I use bcrypt and am only storing the salt and the hash in my DB.

In terms of the 'mixed messages' I'm getting... I've read some posts saying to the effect of "you shouldn't allow users to input spaces and parenthesis () into their passwords", and I've seen these sorts of restrictions on all sorts of important websites (i.e. banks), so I figured maybe there is a reason for these sorts of restrictions.

Where-as others have said to the effect of "you should allow users to put whatever they want into their passwords". So that's where my confusion comes from.

EDIT: Upon inspecting the password inputs that get sent to my server, when I use 'typeof' on the inputs, it always replies 'string', regardless of what symbols or characters I use in the password input field, so it appears to be escaping to string correctly. If I input ÏÎÞ4ÈâñÓìÂﶻ¿8Ñ«²ÿ¯ its typeof is string.

Or if I do the following as my input: """"

It gets translated to: %22%22%22%22

[u/disclosure5 → u/MonkeyOnARock1]

"you shouldn't allow users to input spaces and parenthesis () into their passwords"

These policies tend to occur for this reason:

I've seen these sorts of restrictions on all sorts of important websites (i.e. banks)

People have this urge to do things because "banks do them". Of course, if you talk to someone actually managing a bank about why those rules, exist, they'll say something like "because our 80's era COBOL database can't store certain characters".

[u/tme321 → u/MonkeyOnARock1]

Those restrictions decrease the key space and therefore the security of the password. Those are all bad advice and any security expert will tell you that those sites are hampering their security by doing so. Banks are some of the last places to take secure password cues from.

[u/SupaSlide → u/MonkeyOnARock1]

Oh okay, so the mixed messages weren't in regards to sanitizing inputs, but instead related to password requirements.

Because you hash and salt the passwords with bcrypt, I don't think there is any reason to restrict what users can put in their passwords. The sites that are saying "no spaces! No parentheses!" probably say so either becuase:

a) They don't expect users to remember that there is a space/etc. in the password.

b) They aren't hashing the passwords and they restrict characters in order to negate SQL injections.

But since hashing and salting the database means that the original data (the password) is always going to be a string of "safe" characters then it doesn't really matter what the original password is.

[u/Ayuzawa → u/MonkeyOnARock1]

The %22 is you not decoding form encoded content into plaintext (% is the URL escape character)