Subscribe to Who needs shades of grey?        RSS Feed
-----

Passwords and that annoying CAPSLOCK problem.

Icon Leave Comment
There is nothing I'm more interested in than usability, unless it's security. Or something else if it's shiny. So I'm going to talk about all of these things.
You're familiar with users typing in their passwords and not being let onto a site because they unfortunately forgot they had caps lock enabled. The scenarios for can be broken down quite easily, and it turns out not to be such a problem after all.

The conventional solution to this is to do one of the following:
1. Tell the user their login details were incorrect and leave them to figure it out for themselves.
This is the default for most apps. It's crap.

2. Detect all caps in the username and throw an error saying "did you have capslock enabled?"
Better, still annoying for the users who just want to shout "you know I do, figure it out!" to their computer.

3. Just throw an error saying "did you have capslock enabled?" regardless.
Yeah. Boring.

4. Actually detect capslock during input and throw a warning.
Not bad - probably the best-practise solution. Check http://dougalmatthew...ting-caps-lock/ for a good snippet to do this for you. Downside is that it only works if the user has enabled javascript.

4. Force the input to be lowercase (or upper) by running some kind of strtolower() or equivalent on it
Dramatically reduces the number of possible passwords. Very bad for security. Stupid, in fact. Also have to remember to do it when updating the passwords as well :)

5. Do the password check case-insensitively.
Moronic. Only possible if the target password is stored as plain text. Don't do it.

So, to summarise, the best solution is to perform (4) on the client side and get the server to throw back a response based on (2) or (3) if you don't receive some sort of "javascript enabled" type hidden field.
Or is it?
There's a better way. Better, that is, for frustrated end-users: check against the inverted-case password

John has a username of "John999" and a password of "pAssW00rd!?".
If there's a user with that name, proceed as usual. If there's a user with the name "jOHN999", then also check against the password "PaSSw00RD!?". Or even miss out that step and check against both passwords in the first place.
This effectively solves the issue, except in the case where the user turns capslock on duRING TYPIng their pASSword. If they do that and can't be bothered to try again, they don't get any cake. This method silently lets them in (well, you could alert them about it after the fact) at the cost of making their password twice as easy to crack.

Twice as easy to crack? Isn't that really bad security?
Well, no. Not really. Adding one character to a password will make it (length * size_of_character_pool) harder to guess (say, 6 * ~75 = ~450 times harder for an average short password) even if the password length is already known by the cracker (unlikely) so we're talking about a drop in the ocean. Better to allow inverted caps on the front door and enforce a minimum complexity when setting the password in the first place.

I'm talking about lowering barriers to letting legitimate users into the site - because sometimes people get frustrated and turn away to do something else even when it's their fault.

0 Comments On This Entry

 

October 2018

S M T W T F S
 123456
78910111213
14151617181920
21 22 2324252627
28293031   

Recent Entries

Recent Comments

Search My Blog

0 user(s) viewing

0 Guests
0 member(s)
0 anonymous member(s)