(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:
- visits http://beamauth.org/login, either manually or because some other site redirected her there (with OpenID, for example),
- clicks her BeamAuth bookmark, which automatically fills in her username into the login form and “injects” a secondary secret token into the page scope,
- enters her password into the form,
- 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.
Benlog 
Comments
26 responses to “BeamAuth: Two-Factor Web Authentication with a Bookmark.”
Why didn’t you just use Client SSL certificates? Much less complicated for the user, and verifiably secure.
Why didn’t you just use Client SSL certificates? Much less complicated for the user, and verifiably secure.
Yes, a client-side SSL certificate would solve this, but I have trouble seeing how it’s less complicated for the user. As far as the user is concerned in BeamAuth, they just drag and drop a bookmark, and click it before typing in their password. Compared to generating a key, installing it in their browser (some browsers don’t support multiple client-side certs well, btw), I think this is simpler. A real usability test is in order, of course.
Yes, a client-side SSL certificate would solve this, but I have trouble seeing how it’s less complicated for the user. As far as the user is concerned in BeamAuth, they just drag and drop a bookmark, and click it before typing in their password. Compared to generating a key, installing it in their browser (some browsers don’t support multiple client-side certs well, btw), I think this is simpler. A real usability test is in order, of course.
Ben,
This is a really cool idea.
The usability looks right.
Users I think can appreciate
that ‘precautions’ are needed and some notion
of a special “bookmark key” makes sense.
With regard to your ‘name’
FragToken Bookmark Authentication,
how about BAT-key
for Bookmark-Authentication-Token Key?
Ben,
This is a really cool idea.
The usability looks right.
Users I think can appreciate
that ‘precautions’ are needed and some notion
of a special “bookmark key” makes sense.
With regard to your ‘name’
FragToken Bookmark Authentication,
how about BAT-key
for Bookmark-Authentication-Token Key?
[…] http://netmesh.info/jernst/Digital_Iden […]
Hi Ben – I think your solution is a great contribution. Two questions: first of all, why is this a browser problem? Why can’t people just modify the email clients to solve this? (Since phishing seems to be almost entirely about getting a link in an email where the text does not match the URI behind it) Because after all, nobody actually types in: http://scaryurl.ru/gatherpasswords.cgi, right?
Also, aren’t there other ways to solve this that would work 99% of the time? So maybe a browser could, before hitting any site that wasn’t typed in by a user, check online and see if the site existed a month ago. Or maybe it would see if anything on that site was in my cache first (as my real bank site would have entries there). These would require browser changes, though.
Lastly, what about what Brookline Bank just did to me? It forces me to “register” my IP to use their site now. So if I hit it from somewhere else, I must re-register that by them sending a passcode to my email address. In this case, if I got phished, someone couldn’t access my site even with my credentials.
Hi Ben – I think your solution is a great contribution. Two questions: first of all, why is this a browser problem? Why can’t people just modify the email clients to solve this? (Since phishing seems to be almost entirely about getting a link in an email where the text does not match the URI behind it) Because after all, nobody actually types in: http://scaryurl.ru/gatherpasswords.cgi, right?
Also, aren’t there other ways to solve this that would work 99% of the time? So maybe a browser could, before hitting any site that wasn’t typed in by a user, check online and see if the site existed a month ago. Or maybe it would see if anything on that site was in my cache first (as my real bank site would have entries there). These would require browser changes, though.
Lastly, what about what Brookline Bank just did to me? It forces me to “register” my IP to use their site now. So if I hit it from somewhere else, I must re-register that by them sending a passcode to my email address. In this case, if I got phished, someone couldn’t access my site even with my credentials.
Really interesting idea.
>Alice was expecting to log in to a specific web site (which is now lost)
It doesn’t need to be lost 99% of the time. When the user first hits the site with it in the URL and you show them a page that says please use your bookmark, if they have cookies enabled and you can do session tracking, start the session when they first hit the page add the URL parameter to the session and retrieve it after they use their bookmark to log in. Not pretty but more usable.
What are you going to do if they loose their bookmarks, or are traveling and don’t have them? What will be the “back up” login be? How will you secure it so phishers don’t just use that method instead. ie the phisher puts a page to the user which says, sorry we are having problems right now, please enter your username, password, and additional info to authenticate (The info required if you loose your bookmark.) I guess I don’t have a clear understanding of how guable users are. Would they just believe your system was having problems and enter the additional info?
Really interesting idea.
>Alice was expecting to log in to a specific web site (which is now lost)
It doesn’t need to be lost 99% of the time. When the user first hits the site with it in the URL and you show them a page that says please use your bookmark, if they have cookies enabled and you can do session tracking, start the session when they first hit the page add the URL parameter to the session and retrieve it after they use their bookmark to log in. Not pretty but more usable.
What are you going to do if they loose their bookmarks, or are traveling and don’t have them? What will be the “back up” login be? How will you secure it so phishers don’t just use that method instead. ie the phisher puts a page to the user which says, sorry we are having problems right now, please enter your username, password, and additional info to authenticate (The info required if you loose your bookmark.) I guess I don’t have a clear understanding of how guable users are. Would they just believe your system was having problems and enter the additional info?
Thanks for all the fantastic comments!
– Richard: I like BATkey! Or BATlogin, because Authentication Token Key is a bit much. But that’s a great acronym, I think I’ll try it out on a few people.
– Ed: in the case of OpenID and other single sign-on providers, email isn’t ever part of the phishing problem. You go to a site, e.g. a blog, you click “login using my OpenID”, you enter your OpenID URL, and the web site sends you to your OpenID provider to log you in. So yes, in the classic email-based phishing scenario, email clients can do a lot to protect users. In the single sign-on case, email isn’t part of the loop. Regarding other browser-based solutions: yes, many approaches might work. I was looking for something without browser modifications.
– Christopher: you make an important point. There cannot be a backup login system that is single-factor. If you lose the bookmark, it can be sent back to you via a different channel, like email. But you can never log in with your password alone, otherwise the entire scheme is shot.
Thanks for all the fantastic comments!
– Richard: I like BATkey! Or BATlogin, because Authentication Token Key is a bit much. But that’s a great acronym, I think I’ll try it out on a few people.
– Ed: in the case of OpenID and other single sign-on providers, email isn’t ever part of the phishing problem. You go to a site, e.g. a blog, you click “login using my OpenID”, you enter your OpenID URL, and the web site sends you to your OpenID provider to log you in. So yes, in the classic email-based phishing scenario, email clients can do a lot to protect users. In the single sign-on case, email isn’t part of the loop. Regarding other browser-based solutions: yes, many approaches might work. I was looking for something without browser modifications.
– Christopher: you make an important point. There cannot be a backup login system that is single-factor. If you lose the bookmark, it can be sent back to you via a different channel, like email. But you can never log in with your password alone, otherwise the entire scheme is shot.
Two Factor Authentication with a Bookmarklet…
I’ve been meaning to write about this all week, but kept forgetting. Ben Adida has proposed a two-factor authentication scheme using a bookmarklet which looks pretty cool. Ben calls this a “bookmark,” but I prefer “bookmarklet” since it’s a……
Thanks Ben, was trolling around for some possible solutions to solve my single factor authentication issues that provide more protection from phishing attacks. I might be misinterpreting what Ed meant but one way to avoid the classic phishing attack in email is not to allow for a user-password combination to be entered for authentication or lost bookmark as Christopher put it upon being forwarded to the site from email.
It wouldn’t work in all situations but one way would be to redistribute a bookmark to known secure email address upon request by the user. It would require them to replace their old bookmark but it would prevent an attempt and someone hijacking that information and passing you on to the actual site.
Think I’m outside of the initial scope this was meant to address but if the bookmark was only provided by email I think it may add something for some.
Long time no-see by the way!
Thanks Ben, was trolling around for some possible solutions to solve my single factor authentication issues that provide more protection from phishing attacks. I might be misinterpreting what Ed meant but one way to avoid the classic phishing attack in email is not to allow for a user-password combination to be entered for authentication or lost bookmark as Christopher put it upon being forwarded to the site from email.
It wouldn’t work in all situations but one way would be to redistribute a bookmark to known secure email address upon request by the user. It would require them to replace their old bookmark but it would prevent an attempt and someone hijacking that information and passing you on to the actual site.
Think I’m outside of the initial scope this was meant to address but if the bookmark was only provided by email I think it may add something for some.
Long time no-see by the way!
This a really interesting idea. The team I work with is always looking at interesting way to provide a second factor of authentication.
We are also very interest in the progression of OpenID. We are developing a implementation of strong,
multi-factor authentication for OpenID, which is currently in Beta:
TrustBearer OpenID.
We’ve been concentrating on simple user experience at this point, and we are interested to learn what sort of features user will look for in this type of implementation.
With our OpenID, you basically just set-up a strong authentication device and then link the device to your OpenID URL. Factors besides devices, are interesting to us, however.
This a really interesting idea. The team I work with is always looking at interesting way to provide a second factor of authentication.
We are also very interest in the progression of OpenID. We are developing a implementation of strong,
multi-factor authentication for OpenID, which is currently in Beta:
TrustBearer OpenID.
We’ve been concentrating on simple user experience at this point, and we are interested to learn what sort of features user will look for in this type of implementation.
With our OpenID, you basically just set-up a strong authentication device and then link the device to your OpenID URL. Factors besides devices, are interesting to us, however.
I really like your ideas man. As big a threat as Phishing can be victims of such acts are generally uneducated or less then tech savvy individuals. I do want to see Two factor authentication continue to grow both technically and in popularity but I’d also like to see the general public become educated and learn how to use the internet properly, and securely as well. This would cut down on security related issues quite a bit.
I really like your ideas man. As big a threat as Phishing can be victims of such acts are generally uneducated or less then tech savvy individuals. I do want to see Two factor authentication continue to grow both technically and in popularity but I’d also like to see the general public become educated and learn how to use the internet properly, and securely as well. This would cut down on security related issues quite a bit.
Phishing is brutal and I’ve seen it wreak it’s havoc on many an unsuspecting user. Though it has been compromised in the past, Two Factor Authentication is still the safest bet in the battle against cyber crime and even in office thievery. As time passes I expect to see the technology become even more secure and more difficult to break…let’s hope so anyway.
Phishing is brutal and I’ve seen it wreak it’s havoc on many an unsuspecting user. Though it has been compromised in the past, Two Factor Authentication is still the safest bet in the battle against cyber crime and even in office thievery. As time passes I expect to see the technology become even more secure and more difficult to break…let’s hope so anyway.
Phishing present many problems for many people. I have witnessed many people trying to use sites that they believe to be legitimate but are actually spoofed. I believe the best protection against this type of attack is Two Factor Authentication. Though some may claim it’s not sufficient enough in the battle against phishing, it’s certainly better than a simple username and password!
Phishing present many problems for many people. I have witnessed many people trying to use sites that they believe to be legitimate but are actually spoofed. I believe the best protection against this type of attack is Two Factor Authentication. Though some may claim it’s not sufficient enough in the battle against phishing, it’s certainly better than a simple username and password!
[…] BeamAuth: Two-Factor Web Authentication with a Bookmark […]
[…] BeamAuth: Autenticación Web de Doble Factor con un Bookmark […]