BeamAuth: Two-Factor Web Authentication with a Bookmark.

(There’s always a dilemma between “publishing soon” and “polishing for peer review.” This is my first attempt at blog-based collaborative peer-review. Let’s see how it goes!)

The Problem

Phishing is a serious issue, and it’s only getting worse. Through various means, Alice ends up at a spoofed web site she thinks she recognizes (usually her bank). She inevitably ends up providing her login credentials, which the attacker can then use to perform (malicious) actions on Alice’s behalf. Theoretically, assuming Alice’s browser is relatively secure, she could check the URL and the SSL certificate and defend against these kinds of attack. In practice, users don’t check the URL or are easily fooled by similarly spelled URLs and other dirty tricks.

Various anti-phishing solutions in the past help to some degree, though they all tend to have one annoying property: if the user is really not paying attention, if the anti-phishing solution errors out, the user gets phished.

That’s not okay. We need a solution where, if the proposed solution errors out, the user may get denied access, may become confused, but she cannot get phished. At a high level, this requires two-factor authentication, where even if the user gets fooled into revealing the password she knows, that’s not enough for an attacker to gain her full login credentials.

OpenID and CardSpace

The OpenID project is a distributed, web-based single sign-on system that requires no changes to the user’s browser. Unfortunately, as Kim Cameron and Ben Laurie have recently pointed out, OpenID as it is specified makes phishing worse, because an attacker can simply offer OpenID logins on a semi-legitimate web site and then play Man-in-the-Middle for the user’s OpenID login page. OpenID folks have mostly ruled this issue out of scope, which is unfortunate. As it stands, OpenID makes things less secure than they currently are. Some folks are trying to address this issue by augmenting OpenID with other features, for example using a browser plugin. There are also signs that the OpenID community is starting to take this concern more seriously, though no good solution exists yet.

Meanwhile, Microsoft is about to deploy CardSpace, a radically new way to authenticate to web sites, with a significantly revamped client-side experience. On technical grounds and security, CardSpace appears to be quite solid. I’m most impressed with the user interface aspects, which really make it much harder to get successfully phished. Unfortunately, deploying CardSpace on both client and server is fairly involved, and may take time.

So the question is: can we find a middle ground? Something that is more secure than the OpenID spec, but not quite as involved as deploying CardSpace? Ideally, something that doesn’t even require a plugin? We don’t have to have the entire feature set of CardSpace, but at least we should aim to make phishing far more difficult. And, ideally, we could make this OpenID+, something that only slightly alters the model for OpenID, while leaving the existing protocols in place.

Last Minute Edit: looks like CardSpace and OpenID will soon have a collaboration story. I don’t think this reduces the need for an immediate anti-phishing solution with minimal client-side work, but it’s an interesting move nevertheless.

Related Work

In recent days, Simon Willinson and then Ka-Ping Yee proposed having Alice use a bookmark to reach her OpenID server, rather than rely on the web site to redirect appropriately. This is interesting, and one of the OpenID implementors, JanRain, thinks so too.

(In the interest of full scientific disclosure, I was working on a bookmark-related idea independently and around the same time as Simon and Ka-Ping, but they published their ideas first. There is a substantive difference between their proposal and mine, so this presentation should still be useful.)

A Proposal: BeamAuth

What if a bookmark could be a second factor for authentication? In this proposal, the bookmark is more than a server locator: it also contains a secret token. It would be useful if the login process that folks are used to is not radically altered. Because this is BookMark Authentication, or BMAuth, my proposal is called BeamAuth.

With BeamAuth, Alice registers with a web site (which may be an OpenID provider), http://beamauth.org, and obtains some kind of confirmation page which presents a special bookmark, “BeamAuth,” which she can drag to her bookmarks bar. This bookmark contains, within it, a secondary secret token, randomly generated by beamauth.org, that complements Alice’s password.

Later, when Alice wants to log in, she:

1. visits http://beamauth.org/login, either manually or because some other site redirected her there (with OpenID, for example),
2. clicks her BeamAuth bookmark, which automatically fills in her username into the login form and “injects” a secondary secret token into the page scope,
3. enters her password into the form,
4. and submits the form.

How does this prevent phishing?

• URL checked by BeamAuth: If Alice clicks her BeamAuth bookmark at a location that is not her proper login page, the bookmark sends Alice to her actual login page. Some confusion may ensue since Alice was expecting to log in to a specific web site (which is now lost), but at least Alice won’t enter her password on a phishing site. In other words, as long as Alice remembers to click her BeamAuth bookmark before typing in her password, her password is safe.
• Two-Factor Authentication: If Alice is somehow duped into typing her password without clicking her BeamAuth bookmark, she only reveals her password, not the second secret token within the bookmark. The attacker only obtained half the login credentials, while the other half remains safely hidden inside BeamAuth.

If you like this already, you might wonder, “why not just have the password in the bookmark so Alice doesn’t have to type anything?” Well, that would work, too, and it would be phishing-proof, but it seems preferable to make sure the bookmark is not entirely sufficient to perform the login, just in case an attacker gains physical control of Alice’s machine for a few minutes (lunchtime attack).

How Does This Work?

The bookmark looks like:

http://beamauth.org/login#ben@adida.net|8b7c8xcv882340235098142308

Thus, if you are at the location http://beamauth.org/login, as you are when you are redirected for single sign-on, e.g. OpenID, this does not cause a page reload, it simply appends everything after the “#” sign to your URL address bar. This portion of the URL is called the fragment identifier. Crucially, it isn’t sent over the network. However, your login page’s Javascript can pick it up and use it for computation, which is exactly what BeamAuth does. Specifically, BeamAuth Javascript HMAC’s the user’s password with the bookmark token as a key, all inside the web browser, and the result is the user’s login credential.

The URL before the pound sign has to match exactly, though, which means that if request parameters are required, they should be sent to the URL via a POST, or stored in the server-side session. In Opera and Safari, only the latter solution (parameters stored in the server-side session) works, because a click on the bookmark will always cause a reload in Safari, and in Opera if the URL is the result of a POST.

Is This Really Better?

I think so. The current JanRain implementation of Simon’s suggestion might still lead a user to be phished: an evil web site sends the user to a spoofed login page, which happily accepts his password. In other words, a momentary lapse of judgment on behalf of the user will still result in the user being phished. I don’t think this can happen with BeamAuth, mostly because BeamAuth is a two-factor solution.

The only downside is that BeamAuth requires Javascript. If you have Javascript turned off, you’re still safe, of course: an attacker can’t log in. But then again, neither can you. One solution is then to send the secondary token to the server directly over SSL, without Javascript on the client. I like this less, but it’s workable.

Extensions

Of course, passwords shouldn’t be transmitted in the clear, and neither should our computed credential which results from two user factors. The computed credential should be exchanged over SSL or using a challenge-response protocol. That’s not too hard to implement. What’s interesting is that, if you’re not worried about IP/DNS spoofing, you can safely use BeamAuth without SSL. That’s a bit dangerous, but it’s likely more secure than using a login server over SSL without BeamAuth, because users never check the SSL padlock anyways.

There may be a way to provide a more consistent experience across all browsers using bookmarklet tricks. I’m exploring this possibility with Filipe Almeida. The trick is to find a piece of Javascript that the phisher cannot hijack, which is a lot harder than it sounds.

Demo!

I’ve implemented this over on Demo Server, which is part of a conference submission that includes other work using the URL fragment identifier for added security. Thus, the name on the Demo Server is FragToken Bookmark Authentication (if someone has a better name, I’m all ears!)

Acknowledgments

Rachna Dhamija provided important usability feedback on BeamAuth. Filipe Almeida and Ben Laurie provided crucial security feedback and broke an early version of BeamAuth.

You can also read the paper in submission.