Thursday, July 8, 2010

Throw this phish back: Separating the userid and the password

Many financial services are implementing stronger security measures these days, from chip-and-PIN to security questions.  Any credit card that is underwritten by FIA Card Services, if it hasn't already, will be undergoing a new set of measures to prevent phishing attacks.

I encountered the first steps of this on my Schwab VISA the other day: splitting the password from the userid screen. As a security principle, meting out the authentication steps is a spectacular idea to prevent automated attacks. And, because the user is supposed to have personalized the information on the authentication page where she enters her password, eliminates phishing attacks. (Phishing, for those who have been living under a rock for the last 15 years, is the practice of sending emails to people that look real but are not, and which ask for personal information or passwords. When the diligent but unsuspecting user clicks the link in the email, it leads to a web site that also looks real but isn't. The user enters userid, password, and possibly other personal information, and now has surrendered it all to the phishing scammer.)


Because you don't pay attention to who you get email from, we're giving you more work 

The ideal interaction works like this:

Login page: User enters the userid, clicks Submit.

Authentication page: User sees an image and a pass phrase she has entered into a profile previously and then enters a strong password, clicks Submit, and goes to the site.

The added steps should help customers recognize that they're in the right place when they've clicked a link from an email, without taking more than a couple of seconds extra when compared with the userid/password combined page.

In reality, the interaction works like this:

One day, the user goes to her credit card's web site to schedule a payment for her bill. When she arrives, she finds that the site has changed from having the userid and password on the same page to separating them -- without notice.

On the login page, the user realizes that her personal single sign-on will now not work.

Now the strong password generated and stored by her password-managing software must be exposed, because she has not memorized it. She logs in to the password-managing software and opens the record for the web site, which unmasks the password. Then she can copy and paste the strong password into the new authentication page.

By the way, the answer to her security question is her mother's maiden name, which is easily findable by others. There were 5 images offered, one of which was a flower, which would be easily guessable by someone who knew that the user was a middle-aged American female.


As a security measure, this stinks. As a user experience, it is abysmal.

The credit card company (and other financial services companies that use this authentication schema) has traded off one set of security issues for another. That is, because the financial services company gets blamed when there's a phishing attack, they put more security steps on the user. It is unclear whether the credit card company has weighed the direct cost of the burden of their added steps. Most certainly they have not looked at the user's context to understand how their measures fit into users' goals.


Why the security is still lacking
Splitting the userid and password onto different pages makes using a strong password more difficult. In the case of using personal single sign-on, we now have an opportunity for shoulder surfing, when we didn't before.

The images available as site keys are very easy to guess if you know anything else about the user.














Answers to security questions are easily findable if you know anything else about the user.

























A user experience of -3
Imagine that this user has something like 15 to 25 userids and passwords that she uses as frequently as daily or weekly. For today's scenario, the user's goal is to check a balance, pay a bill, or maintain the account in some other way. Authentication enables the task. It is not a task in itself. No one goes to a web site with the goal of logging in.

This so-called enabling task is a burden. And the very things that make it a burden allegedly make each site more secure. The added steps took much more time to implement and then use than the promise suggested. The added steps also had (we assume) the unintended consequence of causing the user to expose her strong password.

Include in the scenario that the change in security measures was a surprise. It's a question of degree: A userid/password combination on the same page is something many people are used to; it was a small bump on the way to accomplishing a task. Splitting the userid from the password was disturbing, distressing, and disruptive. Adding other measures to the authentication page was burdensome, annoying, and failed to demonstrate how implementing them helps the customer.





Making security decisions is complex. Making them in the context of users' work is nearly unheard of. These authentication measures are clunky and burdensome because they've been bolted on to the site rather than built in to the experience.  There must be a better way – a more effective, less burdensome way -- to prevent phishing and secure users' data.


2 comments:

  1. I'm glad somebody as smart as you is working on this stuff, Dana.

    I do have to say that the "Is *this* your card?" part isn't always that lame, though. It's been years since my bank made me choose a photo which would prove they were them, so I can't remember exactly how many there were to choose from. But there must have been hundreds for me to end up as with something as specific and esoteric and personally meaningful as a photo of a.... Oops! You almost got me there, darn you.

    Keep up the good work, and please do write more about the topic.

    (BTW, have you started getting the quasi-convincing fake order confirmations from "Amazon"? I've started getting several a day, and I'll bet they're hooking a lot of phish.)

    Steve Krug

    ReplyDelete
  2. Hi Steve,

    Thanks for the nice comments.

    It's not always lame, you're right. But even if there are 100 images available to choose from, how often do you change it? If you don't -- and these systems are serviced with the same image database from bank to bank, brokerage to brokerage -- 100 is a small set to break if your a cracker.

    From the user side, how many sites do you use that use the image identifier to prevent phishing? Certainly it is easier to remember if you a) use the site frequently and b) have to use the method on only a few sites. If you have a lot of sites where you have to recognize an image, you're likely to choose the same image, or the same type of image if you can. If you don't use the site frequently, it's easy to forget what you chose.

    Oh, and don't worry, I already know that you chose a sports image or a picture of a beautiful woman.

    No, I haven't been getting the fake order confirmations from Amazon. If you could send me a couple of screen shots, that would be awesome.

    ReplyDelete