The problem with passwords

In 2009, Marsha and Michael Shames-Yeakel, sued Citizen’s Bank in the United States for the loss of $26,500 as a result of a successful phishing fraud instance against their home equity line of credit. The plaintiff’s position, successfully argued, was that Citizen’s Bank did not adequately protect them because they did not implement the FFIEC guidelines as to the use of two-factor security or authentication (2FA) for Internet banking access. The successful case has significant implications in the United States, where the majority of banks are still to implement 2FA. In the EU region, two-factor has been common for sometime and is a legislated requirement for both Internet Banking and SEPA. However, we’re becoming increasingly aware of the weakness of basic security built up around passwords or PINs. While 2FA is a good solution right now, clearly the chink in the armor is the password mechanism itself. I thought I’d share some research and thoughts on this that are great principles when you’re looking at digital security in the user experience.

Common passwords are a big security risk

Joseph Bonneau, Sören Preibusch and Ross Anderson analysed 32 million passwords stolen from the RockYou social gaming Web site in 2009 and 200,000 iPhone unlock codes before carrying out an online survey of more than 1100 people for what they claim is the first quantitative analysis of the difficulty of guessing four-digit banking PINs chosen by the cardholder. They found that thieves can expect to crack 1 in 11 stolen cards due to the common reuse of classics like 1111 and 1234.

Splashdata likewise analysed millions of passwords used in eCommerce and Internet Banking fraud, and found the most common passwords are also the most readily used to execute fraud. SplashData created the rankings of ‘worst passwords for 2011′ based on millions of stolen passwords posted online by hackers. Here is the complete list:

1. password
2. 123456
3. 12345678
4. qwerty
5. abc123
6. monkey
7. 1234567
8. letmein
9. trustno1
10. dragon
11. baseball
12. 111111
13. iloveyou
14. master
15. sunshine
16. ashley
17. bailey
18. passw0rd (’0′ zero used instead of ‘O’)
19. shadow
20. 123123
21. 654321
22. superman
23. qazwsx
24. michael
25. football

So one might conclude by this that issuing a more complex PIN, forcing customers to cycle passwords, or choose passwords with say one capital letter, and a mix of alpha-numeric passwords might make Internet Banking safer, and more secure. But actually you’d be wrong. There’s a false economy there.

Longitudinal analysis of password behavior

Between 2004-2006 Peter Brooks and Michael Armstrong at HSBC eCD (e-Channel Department as it was then known), along with myself and David Jacques, embarked on a series of usability tests looking at password interaction and memory load. We tested multiple password mechanisms in a champion/challenger environment using retail banking consumers, we filmed these encounters, and we also used HSBC call centre staff to test the impact of these various mechansims over a period of 6-8 weeks to see what role memory played in security interactions.

What we found out is essential learning for anyone working on digital channels these days trying to improve security. There were many interesting findings, but here are four that I’d like to share:

Two-Passwords and the Memory Load Problem

We tested the use of a normal User ID & Password combination, but then added in a second password. In this instance we tried calling it a secret word, a verification word and a second password. Users frequently got the two passwords confused, not sure which order to put them in. Secondly, the additional memory load meant that around 30% of the customers wrote down or stored their second password in a plain text file, so they could access it later if they forgot it.

At the time we asked the Usability Guru Don Norman for his input into what we were observing and he gave us a classic quote that is so applicable to this debate on password security:

“The more secure you try to make a system, the less secure it is likely to become” – Don Norman, NielsenNorman Group

We saw over and over again that when you made it hard to remember a password, people would find workarounds. Post it notes on their monitor, plain text files stored on the desktop, a memo note on their smartphone. The harder it was to remember, the more people resorted to the least secure mechanisms to recall the password. This played into our second use case also.

When you increase memory load, people use workarounds which reduce security

The random letter selector

In the tests we had users test a password mechanism I’ve seen in use occasionally which involves asking users to select the 2rd, 5th and 7th character of their password. The idea behind this is from security experts that say that if someone is using sniffers or keystroke logging tools that this avoids them learning the entire password at any one time. However, this again created memory load issues. To figure out random letters within their password, how did users react or adapt?

“If you ask me for the 3rd or 5th character in my password or if I had to break it into chunks, I’m probably going to have to write it down” – HSBC customer during a usability test

Again memory load presented it’s ugly head. By increasing the workload to remember or break up a password into chunks, the customer commonly wrote down or typed the password into a plain text file on the screen again. Once again, by attempting to make the system more secure, we were actually introducing workarounds that dramatically decreased security.

Online Password Reset (OLPR) Questions

This mechanism is still in use today by many banks and social media networks, etc. That is, if you forget your password you’ve had to answer some questions that only you are supposed to know the answer to. Things like what is your Mother’s maiden name, what was the name of your first pet, your first school, which city were you born in, what’s your favorite movie?

In longitudinal testing over a 2-6 week period, we found more than a 50% failure rate in this methodology. There were two reasons for this. The first that was many of the questions such as favorite movie, favorite book, etc were very subjective and the answers to that question changed week to week. The second problem was inconsistent use of the ‘answer’ – for questions like your Mother’s maiden name, people got case sensitivity wrong; for first school they sometimes put the word ‘school’ at the end of the school name, other times didn’t; for the city they were born in, it sometimes changed from a local suburb or borough, to the main city closest to where they were born, etc.

'Secret' questions for recalling your forgotten password, have massive failure rates above 50%

The OLPR method proved to be a massive headache creating more customer support and service calls than it saved. The reason we were using OLPR was to stop people having to call the call centre to reset their password, but in fact, OLPR actually resulted in a significant next increase in call centre calls.

Onscreen keyboards and tokens

We tested mechanisms like on-screen keyboards, one-time use tokens or password generators and other such mechanisms. Of these, the token was the only reliable method that consistently was able to be introduced into the standard user id/password system without creating workarounds that actually reduced either the user experience or actual security due to work arounds.

Hence, HSBC was one of the first global banks to introduce one-time password tokens from Vasco back in 2004. Two months after the introduction of tokens phishing fraud had dropped through the floor, and the initial call centre spike for support had returned to normal.

Conclusions

Clearly we’re entering an era (or should it be error) where the simple password and user id combination is no longer secure or robust enough to cope with the myriad of access points we’re using digitally. Increasingly memory load by forcing specific password types, playing with chunks or individual digits within a ‘word’, or adding in additional security words or passwords, is a costly mistake in the user experience as it invariably increases support costs, and reduces actual security due to work arounds.

In this light, the short-term viable solutions are still two-factor authentication. However, longer term, biometrics (voice, facial or fingerprint recognition) that replace passwords is the ultimate solution.

Whenever you ask people to remember a password to access a system, you are inviting risk. Like cash, cheques and branches – passwords are not long for this world.