Phishing and UI: Is the Future our Hope
I’ve been working on requirements for web authentication systems that will help us fight Phishing. My current draft is here. Today, if you make the mistake of sending your password to the wrong place on the web, you have compromised your identity until you change that password everywhere. If you disclose your password to some harmless site it may not matter. However if you have been successfully phished, you have a real problem. Imagine if when you accidentally tried to unlock the wrong car, a copy of your car key, license plate and home address got mailed to the owner of the car you mistakenly tried to open. The web doesn’t work quite that way, but it does have one important property in common. Very simple, relatively easy to make mistakes have significant long-term consequences. My hope is that at least in the case of authentication we can move to a model where that’s not the case.
User interface will be critical to any such transition. During a very long transition period, you will have both the current system and the new system in use at the same time. You need to be able to tell which one you are using. In some ways this will be similar to whether the lock icon is present or not. The UI challenges will be the same, although it may be that the meaning of new mode authentication has less subtlety than whether the lock icon implies that your web session is secure.
Ideally UI can be important in establishing that you connected to the right place after the connection. For example you probably recognize your account balance at your bank. If it is radically different or missing, you could choose to go look at why. If you weren’t able to find an explanation, you could be suspicious of the site. Perhaps you were directed to the wrong place and this is not really your bank.
That’s my hope. However, research is grim on the effectiveness of UI in security. (Other papers draw similar conclusions). Users seem to ignore the lock icon almost all the time. Schemes designed to help users determine if they are connected to the right website also fail; even when something is suspicious, users go on and disclose confidential information. The only thing that has significant promise is cases where the browser can present a warning page about security problems.
My proposal is a bit different. In the case of UI clues like account balance and a list of accounts, the UI clues are related to the task the user is actually trying to perform. It may be less likely that unusual events will be ignored. However users may explain them away as system problems or upgrades.
It’s not clear to me that there is much we can do at all if the user response to UI information is as grim as research hints at. However, I have to wonder what the role of education is in improving things. We spend significant time teaching kids to use a library and other important life skills. How much could we do if we taught class segments in online safety? My mostly unfounded belief is that if we had something reasonably easy to teach and understand that we could significantly improve user response. So, a lot of my goal with this project is to think about what would be easy to teach. What we have today clearly is not. I would not want to explain to someone how to tell from certificate information in a browser whether you have the right site. I actually think it might be easier to talk to people about what makes sense related to the tasks they are trying to perform. Is the information that was there last time still there?
I glanced over something really important: if you can present a clear warning that something is wrong then you have a chance of catching the attention of a lot of users. Strong authentication in the context of federations may allow us to do that in a lot of common attack situations. I’ll come back to that in a future post.