The SiteKey Fallacy

While working this summer a long way from my home bank, I opened an account at Bank of America so I could deposit my paychecks. Before I could do my banking online, though, I had to learn all about their authentication system called SiteKey.

BoA is quite proud of this system, which is designed to avoid phishing attacks, in which some malicious guy (affectionately dubbed Mallory) creates a web site that looks just like Bank of America's, convinces somebody to click that link to login to their BoA account, and steals their password when they try to login. With SiteKey, in theory, the user knows they're logging into the real BoA web site, not some bogus one.

For those too lazy to click the SiteKey link above, it works like this: when you initially sign up for online banking, you choose a unique picture from hundreds of options and you provide a unique phrase. This photo and passphrase together make up your SiteKey. Later, when you want to login, you first enter your Online ID without the password. Then the BoA website shows you your SiteKey. Only Bank of America knows what your SiteKey is, since you created it with their site securely when you signed up, so (theoretically) seeing your SiteKey means you must be at BoA's web site. Now you can safely enter your password and login.

This is terrible for two reasons:
1) There already exists a perfectly good system in place to accomplish exactly the goal of authenticating web sites to end users.
2) SiteKey doesn't work.

I'll address these in order.

First, there already exists a system by which end users can verify that the web site they're viewing is authentic. Basically, when you visit a secure web site, the site provides some sort of proof that it is owned by the organization which claims to own it. When viewing a secure site, most modern browsers show a padlock icon somewhere on the page or in the URL bar, and you can click that icon for more information. Browsers also alert users if they're dealing with a website which can't prove it is who it claims to be. (The details of all this are beyond the scope of this blog entry, but for the curious, look up public key encryption, SSL, and certificates.)

Thus, as long as the user checks for the presence of this padlock icon, as well as the URL which he's viewing (since that's the identity of the web site), he can be pretty sure that any information submitted will be securely transmitted to the person he's expecting to send it to.

BoA does use this system for their web site, but SiteKey is implemented on top of that as a way to make the user feel more secure. While I appreciate the goals BoA seeks by doing this, it's fundamentally a bad idea. Standards exist for the benefit of users. If every web site that wanted to make users feel secure implemented their own solution for the problem, then we'd have countless different solutions, confusing users even more and hurting the overall web experience.

A much better approach is to develop new standards or improve existing standards to solve this problem. That way, users aren't confronted with various different attempts to solve the same problem. This has the added benefit of community involvement, which results in people finding fatal flaws in otherwise great ideas before they're implemented (see below).

In most cases, creating a community standard (or changing an existing one) is difficult. In this case, though, the standard already exists and works fine! The problem is that many people ignore security warnings. A simpler solution, then, is to publicize the existing system and make it easier to use (e.g., by providing better browser support, possibly in the form of extensions).

A much bigger problem with SiteKey is that it simply doesn't work. It makes phishing attacks marginally more difficult, but nevertheless possible. It's fairly simple to break.

Normal phishing attacks look like this:
1) Lure user to evil web site looking just like a real web site
2) Get the user to enter their username/password
3) Save the username/password that the user entered, and forward them onto the real site (or tell them that the login failed, or whatever - you really don't care what happens now, since you have their username and password!)

A SiteKey phishing attack could look like this:
1) Lure the user to an evil web site looking just like the real web site
2) Get the user to enter their username
3) From the evil web site, enter the username into the real BankOfAmerica web site.
4) BoA doesn't recognize the evil web site's computer, so it asks a personal question to verify the identity.
5) Display this personal question to the user, and forward their response to the server.
6) Now that the evil site has answered the personal question properly, BoA shows the SiteKey and asks for a password. The evil site relays that to the user and asks for their password.
7) The user enters their password. The user is toasted once again.

Note that this is only marginally more difficult. Anyone sufficiently motivated who could accomplish the first sort of attack can easily accomplish the latter. So seeing your personalized photo of a cute little puppy might make you feel secure, but don't get too comfortable. You still need to take all the precautions against phishing attacks you always had to take (as I mentioned above: check the URL, and your browser's padlock icon).

It's worth mentioning that this vulnerability has been pointed out before in SiteKey and similar systems, and alternatives have been proposed. Which makes it all the more saddening that another institution I actually care about seems to be switching to a SiteKey-like system.