Response to making a better password fields

Photo credit: Flickr user FORMALFALLACY via Creative Commons

Paul Lewis wrote an article attempting to reduce friction on password fields. He even referenced the wonderful xkcd cartoon on the subject, but I feel concentrating on ways of helping users to see how they can enter a valid password misses the main point of the friction.

The friction is primarily caused by the requirements, be they minimum requirements symbols numbers etc. or maximum requirements like no more than 16 characters, or even worse the password must be between 8-12 characters! Being forced to modify a password to add extra features is likely to cause you to forget it, in the same way that preventing a user from certain length passwords or use of specific symbols will also annoy and lead to forgotten passwords. These restrictions add friction to the password entry screen and anything that can be done to remove these restrictions will reduce friction more than attempting to improve the clarity of the restrictions.

The xkcd cartoon points out that the "Tr0b4dor&3" password is easier for a computer to hack than "correcthorsebatterystaple", yet the second is substantially easier for a human to memorise.

To reduce friction the password field should be made as simple as possible, but assist users in creating difficult to crack passwords.

I would remove the requirement all of the criteria such as upper case, lower case, digits and symbols. Perhaps more importantly allow any character and very long passwords.  Instead of restricting the input and forcing people to use l33t passwords, teach the user how to write and memorise longer passwords.

Using a "complex" password like "Tr0b4dor&3" does not prevent brute force attacks succeeding, the only way realistically is to prevent multiple incorrect entry.

If the only requirement for a password was it has to be 6 characters, even if you enter all lower case that is 308,915,776 possible combinations. Of course if you were to try a dictionary attack then you might restrict this number down to say 50,000 realistic combinations.

Now a cluster of computers could chew through either of those numbers in no time, but if they are restricted in their number of attempts, well then even simple 6 character passwords can become pretty robust.

It is vital if you care about security to monitor the number of successful and unsuccessful attempts to access an account. Start by adding a locking timer after what you consider a reasonable number of attempts. Around 10 attempts should be sufficient and then lock the account for 30 minutes after another 10 lock it and notify the user that their account appears to be under attack.

The only password restriction I would include to the list is to help prevent the use of common passwords. A list of the top 1000 passwords and advise that they have tried to use a common password and recommend trying a different one, or adding an additional pre-fix or suffix to reduce the probability a hacker could guess it.

You can try to add more advanced features like white lists and black lists if the simple lock out above is insufficient and causes too many accounts to be locked out through a DOS attack rather than an attempt to break into accounts.

When you are creating password fields please work towards greater usability and remember that forcing a human to do something they do not want to do will inevitably lead to reduced security as they write down passwords in notebooks or in saved documents on the PC, on post-its, or saving them in a program such as keepass creating a single attack vector for multiple passwords.


Popular posts from this blog

IE9 Intranet compatibility mode in Intranet websites

Intersystems Caché performance, woe is me...

Multi-select with shift on HTML table