Balancing login usability and security
Online security and passwords is a topic that never dies. We are hopeless at being secure, and a whole load of companies have shown they are equally as hopeless at it.
On top of that, hackers have proved time and time again how smart and inventive they can be in order to break things open.
I’m not a security expert, but I am an expert in usability and practical usability. This article is written with user experience in mind and considers how we can make digital services more secure without making users confused, disheartened, angry, or violent (or all of them at once).
We hate passwords. We always have. We are like flowing water when it comes to choosing them; we find the quickest way out – the simplest password possible. More often than not the same as we have used elsewhere. Fred, querty, 123456, 654321, password are some of the timeless classics.
So to make our accounts more secure, online services have over the years forced us to choose more complicated passwords. Usually stipulating various rules such as 10 characters long, a mix of numbers and letters, not one of your previous 6 passwords.
These various rules can make the password more secure, but generally where they succeed best is at making our passwords less easy to memorise. So it increases our need to note them elsewhere (such as on a post-it note under your keyboard), use (roughly) the same password everywhere, or devise passwords that follow patterns.
Then we have the various “security” questions, which are often not very secure at all – your mother’s maiden name, your town of birth. In some countries, a lot of the answers would be very easy to find.
The more serious services (such as banks) have usually deployed electronic devices that generate tokens (“pocket calculators” as I usually call them) as part of their login authentication procedures. These devices are a usability nightmare.
I have three of these things for three different banks. All of them work differently. All of them require a PIN. Two of them require a smartcard too. Not only do I have to remember the PIN, I have to remember the correct sequence of actions and perform them in a little password token dance dictated to me by the website.
The poor usability (in exchange for “my security”) of one particular banking service after they introduced “pocket calculators” as part of the login process became such a point of frustration for my wife and I that we changed bank.
The bank we chose was one that provided two-factor authentication by means of an SMS containing a one-use verification code sent to the mobile number registered with the bank.
Suddenly logging in to a bank became easier than it had ever been. Yes I had to remember a passphrase to start the login process, but the second stage is a simple matter of typing in a 6 digit code that arrives instantly to my mobile phone.
I don’t have to fight with a proprietary token generator. I don’t have to learn anything new. The bank and I are making use of something familiar and widely adopted – receiving and reading a text message.
By utilising a familiar or established process the barrier to use is reduced and usability increased.
I know, I have, I am
Multi-factor authentication is where more than one form of verification is required in order to be identified. The usual building blocks for multi-factor authentication are something you know, something you have, and something you are.
In the example above, I needed to enter a passphrase (something I knew) followed by a token sent to my phone (something I have).
This type of authentication is instantly much more secure than traditional one-step (password based) login.
Even though some point out the potential for a “man in the middle” attack (that intercepts the SMS token) as part of a multi-factor login or even a number porting attack, it’s pretty complicated and involves targeting specific individuals and some social engineering in order to crack the entire login.
If a company gets their (encrypted) passwords leaked such as LinkedIn, Yahoo and Dropbox (to name just three during 2012), having a second step helps lessen the impact of such a failing of their security.
Token generators (“pocket calculators”) or smartphone apps such as Google Authenticator will be usability nightmares for many users.
If we can provide a second verification step in a way that doesn’t significantly impact on usability, then we’re on to a winner.
I think SMS tokens offers us that winning concept.
We are starting to see a number of major players offer are offering text message tokens as part of their multi-factor logins. Facebook, Google, Yahoo and Dropbox are all offering this kind of login (optionally) to their users.
Consider offering 2-factor authentication with SMS tokens for your web-based service. Make enabling and setting up the extra authentication as simple and as pain-free as possible for the user.
A balance not a panacea
SMS tokens aren’t the panacea of login security, but by putting in place security systems that are usable those systems stand a chance of being used as we intended rather than being bypassed and circumnavigated like some of the less usable alternatives.
Balancing login #usability and #security beant.in/U9KFbN #ux
— James Royal-Lawson (@beantin) November 27, 2012