Should users be able to enter a password such as " 12345" or "12345 " – a space at the beginning or end? Or would you trim the password to remove the leading or trailing spaces because it may just a typing error.
相关问题
- How can I implement password recovery in an iPhone
- How can I set the SVN password with Emacs 23.1 bui
- Is the c++ hash function reasonably safe for passw
- Reliably reproduce in C# a legacy password hashing
- Web Authentication - how to securely transfer user
相关文章
- TeamCity Username / password
- Efficient way to aggregate and remove duplicates f
- Creating a regex to check for a strong password
- Handling hashed passwords stored as varbinary in S
- Migrating Existing Users and Passwords to new Symf
- What mechanisms does ssh-agent use to keep unlocke
- Android Oreo: what should I do to publish my app a
- PBE: Verify password before attempting to decrypt
The moment you make such a decision is the moment you start walking down the path of micro-management (over your users in this case).
Does a password containing a space break your system? Or is it a security risk? Then don't worry. Let your users deal with their own errors, even if that means they have to get frustrated. Their typo should never be your problem.
Let me tell you a story.
I needed to create an account on an ecommerce site, so I ran my random password generator to make an 8 character upper/lower/number/punctuation password, pasted it in twice to confirm it, finished registering with all of my personal information, and saved the random password in a local PGP-encrypted file for later use.
Later on I tried logging in, but pasting the password again didn't work. After a bit of testing, I was horrified to find that the site had stripped out all punctuation marks from the original password, in some misguided attempt at sanitization, reducing my password to three easily brute forceable letters.
DON'T trim or sanitize users' passwords.
I don't care. So long as whatever you do to the password when it is being set is also done to it when being entered later on. Trim, truncate, change case, salt, hash, whatever - just do it consistently.
Presumably you aren't storing the actual password anyway, so...
It is fine for the password to contain it as already mentioned however I would add that when generating new random passwords (say for a sensible reset lost password system) you should avoid generating ones containing such tricky characters.
If the password is sufficiently long and random then this will make up for the restriction of a few tricky characters will make the end user's life considerably easier...
Since it's bad juju to store the password as text, there's no need to trim() the password since it'll immediately be hashed.
... on a similar note, am I correct in believing that passwords shouldn't need to be regex validated to for sql injection since they'll be hashed and not inserted as plain text in the database?