tags:

views:

561

answers:

10

Should users be able to enter a password such as " 12345" or "12345 "--a space at the beginning or the end? Or would you trim the password to remove these spaces because it's probably just a typing error.

+22  A: 

Yes, they should.

  • It annoys me to no end when people decide how my password should behave especially when it's nonsensical. I would like more than 8 characters please.
  • You should be hashing the password, so maximum character lengths and spaces at the end don't matter.

No, you should not trim it.

  • You require a user to enter the password twice (when creating it) to eliminate typing errors. Therefore a space doesn't matter.
Tom Ritter
The number of banking and credit card sites that won't let me set my password to space, $, * i.e. non alpha characters beggars belief.
Kev
@Bryan - why should space at the front of a password be treated any differently from say underscore or $. It's a typeable character in the plain old ascii range and hardly going to cause any kind of unicode type wierdness. I think if you can type it it should be acceptable.
Kev
...is the opinion I humbly offer. :)
Kev
why? I guess I haven't thought very deeply about it. My gut reaction is that it would confuse most people, or at least those who are lousy typists and also write their passwords on a piece of paper. I don't think trimming is the best policy, but it may be the more real-world-practical.
Bryan Oakley
I think it's time we stopped worrying so much about the small few people that are too dumb to accidentally put a space before their password, twice, and write it down (bad), and then forget it. They earned it, imo.
GMan
I disagree to this. When typing their password for logging in, someone might copy and paste it, which adds an extra whitespace here or there. If you don't trim this in your login processing code, they won't be able to login even though to them the password is exactly the same. Especially if your audience is non-technical. So no, spaces shouldn't be allowed.
Click Upvote
@Click that's a very good point. I think it's one of those tricky situations. If I had unlimited resources I would detect a paste event versus a type event, and display a message that there was a space at the end of a paste.
Tom Ritter
+8  A: 

You should validate the password with a confirmation field anyway. If they make the typo twice - then you hopefully have a forgot password or a reset feature in place.

The space shouldn't matter as you shouldn't be storing it in plain text.

jfrobishow
+11  A: 

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.

Josh Kelley
Good story, not quite sure it's completely related, but good for people to know/see.
Darryl Hein
I consider it related - he's talking about altering the user's password, so that password attempts that will be accepted are different than (and possibly easier than) what the user may intend.
Josh Kelley
Seems directly related to me.
mquander
Okay, "completely related" meaning that it isn't about a password, but instead about password validation in general, which is what the question has ended up being about. Still +1 for a great answer.
Darryl Hein
Care the share the name of that site? Seems like people really need to be warned.
innaM
Sorry, but this was over ten years ago, and I don't remember the site's name; it was some small music CD shop, I think.
Josh Kelley
+1  A: 

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?

42
I think you'd be correct on the later, except when you using MD5() or something similar directly within within SQL.
Darryl Hein
No input should be regex-validated at all. Just escape all problematic letters.
Georg
@Darryl, Thanks to Jeff's blog, I'm going with SHA256.
42
+10  A: 

Never "clean up" a password simply to account for "typing mistakes". This will confuse users and in some cases make it impossible for them to login. In fact, don't ever change a password behind a user's back...always warn them that a password is invalid and let them try a new one.

A good example that I recently ran into was with a 3Com switch. The web interface allowed me to change the admin password, but didn't warn me that the password was limited to eight characters. I entered a password that was longer than eight characters. When I tried to login after the change, it simply rejected my password. If I only used the first eight characters, however, I was able to login (trial and error on my part, not fun).

Passwords these days don't look the way they used to. For instance, my passwords often look like this:

Man, this program is really ticking me off!
Boden
That reminds me of a bad experience i've had with Windows passwords now on several occasions. I'll build a machine, configure the admin password, and then join it to the domain. The domain imposes password complexity rules that my password doesn't match. Now i can't log in to the admin account. Bah.
Shog9
Back in the dark ages, I had this problem with my AIM account which was an AOL account. Through AOL, I could use my full password, but apparently it just truncated to 8 chars behind the scenes every time, as when I started using stand-alone AIM, I couldn't login until I tried only 8 chars.
rmeador
+1  A: 

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.

Can Berk Güder
You should micromanage and *measure* your user experience. Spin the dials, pull the levers and see what sticks! "Let your users deal with their own errors, even if that means they have to get frustrated" this attitude lacks empathy and not a path I would recommend.
jms
@jms: So you enjoyed using the paperclip in Office, I presume?
Can Berk Güder
+2  A: 

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

Shog9
Good point...checking code...
Darryl Hein
Word. Users are always cutting and pasting text and that last space gets them every time. Trim it, be consistent and don't bother me with it.
jms
Except that you are potentially decreasing the complexity of the password without warning the user. These days people tend to think about things like that.
Boden
@Boden: if you care about strong passwords (and you should) then enforce rules that specify sufficient characters and length needed to make a strong password. If you think it'll make things more usable, then trim. They're not mutually exclusive, so long as you are consistent.
Shog9
+2  A: 

Space is a regular password character, and you shouldn't remove it.

Since you probably hash the password before storing it in the database, the space will be treated as any other character.

muerte
+1  A: 

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

ShuggyCoUk
I generally avoid generating password where possibly, but instead have the user click a link to enter a password if they forget the existing one. One when the admin creates the account is a password generated automatically.
Darryl Hein
that is sensible
ShuggyCoUk
+4  A: 

I've been to a conference more than once where someone logged in to their account for a demo after the computer display was already up on the big screen, didn't change focus to the password field correctly, and thus their password was revealed to the entire audience.

Anyone who might have to enter credentials in front of others should consider keeping a trailing space or three in their password, just in case. And when building authentication systems, you should never trim those spaces.

Joel Coehoorn
Hmm... How long d'ya think it'd take you to guess my password using trial-and-error, if you knew EVERYTHING about it, except for how many spaces i'd tacked on to the end. Including how long it takes me to type it... Hope the guy in your story changed his password after the demo!
Shog9
No idea: I didn't know the presenters. From the standpoint of the hacker, if I didn't know they had appended spaces I would likely assume it had changed. From the standpoint of the presenter I would be hoping it bought me enough time to get through the presentation before changing it, even if the hacker is sitting in the audience with wifi.
Joel Coehoorn