Here’s the BrowserID demo at the Mozilla All-Hands last week:

Given my prior work on email-based authentication (EmID, Lightweight Email Signatures, BeamAuth), you might think BrowserID was my brainchild. In fact, it really wasn’t. And, in a testament to the shrinking impact of academic publication venues, none of the BrowserID team had ever heard of my work on email-based authentication before I arrived at Mozila, even though Mozilla folks are quite well versed in the state of the art. But who cares: when I found out about the ongoing work and how we agreed on just about every design principle, I was incredibly excited. And when I realized the fantastic work the team had already done on defining a scaffolding and adoption path for the technology, I was super impressed.

BrowserID started with the Verified Email Protocol, designed by Mike Hanson and Dan Mills, who came up with the approach after extensive exploration of web-based identity approaches over the last two years. It’s a simple idea: users can prove to web sites that they own a particular email address. That’s how they register, and that’s how they log back in the next time they visit the site. BrowserID, the code and site, was initially bootstrapped by Lloyd Hilaiel and Mike Hanson. Shane Tomlinson and I joined the team in June. We now also have an awesome UX design team (Bryan and Andy) and the team continues to grow (yay Austin!)

So, that’s what I’m working on these days: BrowserID and other Identity+UserData efforts at Mozilla. I’m excited to be leading this technical effort. The team is amazing, and we’ve got big aggressive plans to help you control your identity and data on the Web.

You can think of Circles as the actual circles of friends you have. The things that are easy to do in real life, like sharing a fun anecdote with the friends you generally go out with on Saturday nights, are easy to do in Circles. The things that are hard to do in real life, like planning your best friend’s surprise birthday party with all of his close friends but without him, are no easier in Circles: you have to make a new list of “everyone except Bob.” That’s great, because I don’t think our brains have evolved yet to really feel comfortable with a social model that supports all set operations, e.g. this circle minus this other circle. That’s usually how we get caught lying. (I mean the lies everyone tells as part of their normal social interactions.)

The most important point is that this feature shatters the previously universally accepted idea that privacy must change dramatically given social networking. For a few years, Facebook has defined the Laws of Physics of social networking. On Facebook, it’s not possible to show different people a different face. On Facebook, relationships are, for the most part, symmetrical. And so we all believed that this was the inevitable path forward with social networking. We conflated the fact that users wanted to connect online with the constraints that Facebook created, and we assumed users wanted those constraints. We forgot that software engineers define the Laws of Physics of the worlds they create. We weren’t living in the inherent world of social networking. We were living in Facebook’s definition of social networking.

We now know it doesn’t have to be this way. The Laws of Physics in the online world are mutable. Google just busted open a world of possibility. Users will question, now more than ever, why sharing must work the way it does on Facebook, given that Google has shown it can work differently.

It will make Facebook better. Which will make Google better. And so on. We may be witnessing the beginning of a new era of online privacy, a maturation of sorts. This is an incredibly exciting time.

[I've poo-poo'ed OpenID here and here, because of phishing and privacy concerns. I'm still very worried. I've suggested ways to defend OpenID against phishing, and I helped Creative Commons deploy a privacy-conscious OpenID service.]

What’s fascinating to me is the evolution of OpenID. The pitch used to be “log in with your URL.” The backend protocol was cool, but it didn’t really matter. Authentication was reduced to proving that you own a particular URL: I can prove that I control http://ben.adida.net, thus, for all intents and purposes, that URL is my identity. I *am* http://ben.adida.net. *How* I prove that I own that URL, that’s a good thing to define precisely, but it wasn’t central to the OpenID story.

A lot of folks, myself included, think URLs as human identifiers are not ideal. People aren’t used to them. They don’t provide a communication channel. It is awkward to type a URL into what is effectively a “username” box. Plus, if you give every site your URL, then multiple sites can correlate identities easily, and that’s probably not a good thing when all you really want is single sign-on.

So OpenID evolved. In version 2.0, instead of typing your full OpenID URL, you can just type the domain name of your provider, i.e. yahoo.com. Then, you get redirected to Yahoo, where you log in, and when you’re done, Yahoo provides a pseudonymous identifier to the third-party web site where you want to log in. And as it turns out, that’s exactly the mode of authentication that the government is requiring for its approved OpenID providers, because they don’t want the NIH and CDC to have the ability to correlate your activities across government services. (In passing… how refreshing to see this privacy concern come out of the US government!). So the NIH thinks you’re 83nbxcvndfs34@google.com and the CDC thinks you’re j23nsnsblkjsdfl45@google.com.

My guess is that URLs as human identifiers are effectively dead. OpenID is now the backend protocol. Identifiers are pseudonyms, not public URLs.

I also suspect the next step is a communication channel for these pseudonyms: identity providers will give relying parties a way to send messages to the pseudonyms that logged into their sites, the same way Facebook lets apps notify its users. Something missing in your NIH grant application? The NIH will make an API call to Google saying “please deliver this note to user 83nbxcvndfs34” and Google will forward it appropriately. (Maybe this feature already exists in OpenID 2.0 and I just don’t know about it?)

On the phishing front, OpenID providers will probably duke it out with various mitigating solutions. It would be nice if the OpenID standard tackled the issue, though.

On the privacy front, only the core OpenID protocol can help. I’d like to use my Google credentials to log in everywhere, but I don’t see why Google needs to look over my shoulder every time I log in to every weird site I visit. The only way to fix this is with cryptographic credentials. I don’t see that anywhere in the OpenID spec’s future, but without it, there are going to be deep privacy issues.

In the end, OpenID 2009 looks almost nothing like OpenID 2006. That’s okay, though. One lesson is that, in the end, the OpenID effort inspired and coalesced a number of disparate efforts to achieve an open-standard for web-based single sign-on. Though the solution has evolved significantly, OpenID has succeeded: we have an open web-based single sign-on system. Now, OpenID will have to deal with the consequences of its success. It will get attacked, a lot. Its issues with phishing and privacy will become greater concerns. It should be a fun ride.

But even if you had these building blocks, you would still have to use them in their intended way. A component can only be secure under certain well-defined circumstances, not for any use that happens to look similar.

One area of secure protocol development that seems to consistently yield poor design choices is the use of hash functions. What I’m going to say is not 100% correct, but it is on the conservative side of correct, so if you follow the rule, you (probably) can’t go wrong. You might be considered overly paranoid, but as they say, just because you’re paranoid doesn’t mean they’re not after you.

So here it is: Don’t hash secrets. Never. No, sorry, I know you think your case is special but it’s not. No. Stop it. Just don’t do it. You’re making the cryptographers cry.

What the heck am I talking about, you say? I’ll explain. But before we get lost in the details, just remember. Don’t hash secrets. Ever. Kapish?

What exactly do you mean by “Hash”?

A hash function takes any document, big or small, and creates a short fingerprint. That gigabyte movie of your newborn baby? Hash it with SHA1, and you’ve got yourself a 160 bit (~30 alphanumeric characters) fingerprint. Now, hold on, you say, 30 characters? You’ve hashed my baby to pieces and all that’s left is a measly 30 characters? No, no, don’t worry, your baby is still a unique snowflake. You can’t take those 30 characters and, from them, recover your gigabyte video. This is not uber-data-compression.

But it’s going to be darn hard for you to find any other document, big or small, that hashes to the same 30 characters. In fact, it’s so hard, even the most powerful computer in the world dedicated to this one task for hundreds of years won’t succeed at finding that doppelganger document. You’ve got lots of computers you say? You’re Google and you have hundreds of thousands of computers? Yeah, well…. tough. You still won’t succeed.

In fact, you can try something that should be easier: rather than find another document that hashes specifically to those 30 characters that represent your baby, you can go looking for any two documents that happen to hash to the same thing (collide). And you won’t find any such pair. Promised. We call that “collision resistance”. That thing about how you can’t find another document that hashes to the same value as your baby video? We call that “second pre-image resistance.”

Oh, and I forgot to mention that this magical function, SHA1, is public. Anyone can see the code. There are no secrets. Even if you see the code, you can’t find a collision. No, really, I’m not screwing with you.

I want to hash everything!

That’s usually the reaction after discovering the amazing power of hash functions. There are all sorts of nails just waiting for this magical hammer, so let’s start hashing everything in sight. De-duplicating large documents? Hash and compare! Passwords in a database? Hash and store! Anonymizing names in a database? Hash and pseudonymize!

After all, the magical power of a hash function is that you can’t “go back,” right? Given a hash, it’s impossible to get that pre-image, so hash away, my magical crypto friends!

Wrong.

Yeah, so it’s not quite that magical.

Let’s say I give you a SHA1 hash value 29b0d7c86b88565b78efffeea634cee81a209c92. From that hash alone, you can’t tell what I hashed. But if I tell you that I hashed a password, then all you need to do is try a bunch of common passwords and see which one matches. In this case, I hashed “love”, one of the most common passwords there is.

Now you start to see how this “you can’t go back” reasoning fails: if you know the domain of possible pre-images, and that domain is not too large, then you can just try them all and see which one matches. That’s a big strike against the “hash everything” approach.

Sprinkle in some Salt

It gets more interesting with the complete password use-case. Many web developers already know that they shouldn’t store user passwords in the clear in the database, just in case a break-in reveals every user’s password. So, instead of storing passwords in the clear, let’s store a SHA1 hash of the password, against which a candidate password can be easily checked: hash it and compare.

Now the web developers who have been around the block a few times know that, if you just apply SHA1 blindly, you’ve got the “small domain” problem I just mentioned. An attacker can build up a huge dictionary of hashed passwords just once, and, when he breaks into your web site, check the hashes against this pre-built dictionary.

To prevent these “dictionary attacks”, we add salt to the hashing process, so that each user’s password is hashed differently, and generic attacks don’t work: you have to rebuild the dictionary for each user you choose to attack. Sprinkling in salt is easy: just concatenate the password with a random string:

SHA1("TheAnswerIs42" || "love") = ce75a1c90ed564a231de85d93520f1e47726df64

Then, when a user types in a password, e.g. “lvoe” (a typo), the system checks:

SHA1("TheAnswerIs42" || "lvoe") = f832b210d62251c19a374a175bff760935c540d4
                               != ce75a1c90ed564a231de85d93520f1e47726df64

and sure enough, that doesn’t match, so the password is rejected.

Of course, the system has to keep the salt “TheAnswerIs42″ around to check the password, otherwise, it can’t re-perform the hash. So, if an attacker breaks in, he’ll find the salts, of course. This means that salting won’t protect a user with a weak password. But it will provide better protection for users with reasonable passwords, since, even with the salt in hand, the attacker will have to re-compute the dictionary for each salt, and thus each user.

So the moral of the story is that hashing the secret password directly is a bad idea.

And this is typically where most developers stand. They understand that hashing is good, they vaguely understand the notion of salting, and they figure that salt+hash is all they need to know. Except it’s not.

When hashing is really a signature

One interesting application of hash functions that has spread like wildfire in the last few years is in the realm of cheap signatures. Consider an application, SuperAnnoyingPoke that wants to send an authenticated message to MyFace. It could apply a full digital signature, using say RSA, so that MyFace can be sure that the message really came from SuperAnnoyingPoke. But that actually takes milliseconds on an average computer, and milliseconds are a lot. Plus, there’s all sorts of weird padding issues and size limitations that might require hybrid encryption, so it’s messy.

But hey, let’s take out our trusty cryptographic Swiss Army Knife, the hash function! Let’s salt+hash! We’ll just make sure that SuperAnnoyingPoke and MyFace share a secret string that’s a good 20 characters long or so, and when SuperAnnoyingPoke wants to send a message to MyFace, it will also send along a “Message Authentication Code” (MAC) that is computed as:

MAC = SHA1(secret_string || message)

MyFace can easily look at the message that is sent, recompute the MAC given the secret string it shares with SuperAnnoyingPoke, and compare it to the MAC sent along with the message. Heck, you can even put a timestamp in there to make sure the message can’t be re-played by an attacker at a later date. After all, since the hash function makes it hard to “go back” when you’re using a salt (the secret string), this should be a secure and cheap way to sign messages! Super!

Except this is where things really fall apart.

The security property we want here is that, if the attacker sees a message and its corresponding MAC, then it should not be able to figure out the MAC for a different message. That’s the whole point of a signature. And, unfortunately, there’s a property of SHA1 and lots of other hash functions like it that make it a fast hash function, but a terrible way to compute a MAC.

Here’s the deal: if I tell you that SHA1(foo) is X, then it turns out, in a lot of cases, to be quite easy for you to determine what SHA1(foo || bar) is. You don’t need to know what foo is. It’s just that, because SHA1 is iterative and works block by block, if you know the hash of foo, then you can extend the computation to determine the hash of foo || bar.

Oh crap.

That means that if you know SHA1(secret || message), then you can compute SHA1(secret || message || ANYTHING), which is a valid signature for message || ANYTHING. So to break this system, you just need to see one signature from SuperAnnoyingPoke, and then you can impersonate SuperAnnoyingPoke for lots of other messages.

Why? How??? But…. I thought hash functions didn’t let me “go back!” Well, note how I didn’t say the attacker would recover the secret. It’s just that, given one hash, they can compute others for related pre-images. That’s why you have to be careful about using hash functions when you’re hashing secrets. Another strike against using hash functions willy-nilly.

(If you’re keeping up, your next suggestion is “well, put the secret AFTER the message, not before”. And yeah, that’s a reasonable suggestion, but it points out how you’re now assuming some extra properties of the SHA1 hash function in your design, and that’s bad. What if you upgrade to a different hash function in 5 years, do you then have to update your protocol to match? The point is that you shouldn’t be using a hash function for this, that’s not its purpose!)

HMAC

What you should be using is HMAC: Hash-function Message Authentication Code. You don’t need to know exactly how it works, just like you don’t need to know exactly how SHA1 works. You just need to know that HMAC is specifically built for message authentication codes and the use case of SuperAnnoyingPoke/MyFace. Under the hood, what’s approximately going on is two hashes, one after the other, with the secret combined after the first hash… but don’t worry about it! That’s the whole point! HMAC is built for this feature.

HMAC has two inputs and one output: in go a message, and a secret, and out comes a message authentication code (i.e. a signature). The security of HMAC is such that, you can see as many messages and corresponding signatures as your heart desires, and you still won’t be able to determine the signature on a message you haven’t seen yet. That’s the security property you’re looking for. And HMAC is built on top of a hash function, so more specifically you should be using HMAC-SHA1.

So, again, don’t hash secrets. HMAC them.

In Conclusion

There’s plenty more to read if you’re interested in this topic, but chances are, you’re not and you just want a recommendation. “Don’t Hash Secrets” is not always entirely necessary. In the password example, you can hash a password as long as you salt it correctly. But do you really want to have to worry about that? I don’t. In fact, I use HMAC for my password databases, too. It’s overkill, but it lets me use a standard library that likely makes me safer in the long run.

So the next time you’re using a hash function on anything, ask yourself: is any of the stuff I’m hashing supposed to stay secret? If so, don’t hash. Instead, use HMAC.

But there is one problem: if you write a Facebook application, you’re pretty much stuck with Facebook. Facebook never lets the application see the user’s email address or Instant Messenger account name, or any other fields that would allow the application to contact the user independently. So, unless you convince users to reenter their email addresses, you’re stuck.

Yesterday, Google launched OpenSocial, a generic API for building Facebook-like applications, but this time on top of a dozen competing social networks now all supporting the same programmatic interface. It’s very cool that you can build an app once and run it on any social network, but what’s far more interesting to me is social network portability, the idea that I, as a user, can theoretically pack up my social network and go to a different site altogether, if I so choose. And that as a developer, I can contact users and their friends directly, if users so choose.

I’m not sure yet if OpenSocial will truly allow this, but it looks like it will: the People API has gd:email and gd:im fields which are exactly the key to social network portability: global unique identifiers for your friends that can be used for messaging.

And so OpenSocial will win. Because open is better: more competition and the reduction of artificial user lock-in results in better products. Google has done a very good thing.

One interesting wrinkle: I wonder how the social network operators feel right now. Participating in OpenSocial is inevitable at this point, unless you plan on giving up the significant value that’s about to be created by hordes of developers. But then, how do you compete, as the underlying social network? How do you prevent from bleeding all of your users to a newer, hipper network when users can pack up their friends and applications at the click of a button?

Maybe one way a social network can compete is on privacy: provide very good privacy controls, allow users to present different faces to different sets of friends, and generally make it really worth their while to host their social network with you. Social networks are not going to be judged on their applications anymore, but purely on how well they manage the actual social network data. So maybe, just maybe, privacy will become a competitive advantage.

UPDATE: a little birdie tells me that OpenSocial, in its current form, offers no more data portability than Facebook. That’s unfortunate, but it’s not entirely surprising because of the argument above: social network platforms don’t care to be commoditized. So, if there’s no data portability, but there is application portability, it’s still hard to move from one network to another, and there’s less incentive, since you can use any application on your network. This could completely reverse my point: OpenSocial might cause *more* lock-in, not less, and then there’s no hope for privacy improvements anytime soon.

Jeremy Keith has a fantastic detailed write-up regarding what he calls the “password anti-pattern.” It gets at the same fundamental issue I was talking about, but with more interesting detail. It lays out the problem concisely and clearly:

[Asking for gmail passwords from your users] teaches people how to be phished.

And it mentions OAuth, an effort I only recently learned about, which standardizes the kind of web-based API that would make this practice go away. Fantastic.

But I want to push this a little bit further. The OAuth site talks about ways in which OpenID authentication can be used in combination with the OAuth application API. But OpenID, in its baseline implementation, suffers from the same kind of problematic anti-pattern: it teaches you to be redirected to a login site where you enter your password. Not as bad as entering your password on a different site, but still pretty bad: you now learn that it’s okay to be redirected to your identity provider by any web site, whether or not you trust the web site. And if you don’t check the URL in the address bar (ahem, only security freaks like me do), you’re being taught to be phished, too.

OpenID can be patched to be more secure. But it’s important to realize that, in its baseline implementation, it’s just as bad a user design pattern as the social-network password-based contact importer.

People have been saying this for years, but now the rubber meets the road for real: we need some kind of authentication infrastructure. And guess what… OpenID won’t cut it here, because the issue is to find some way to provide Facebook with a token that it can forward to Zoho that will let Zoho authenticate the user, and since OpenID only supports direct authentication rather than cryptographic-token-mediated authentication, it won’t work. I’m guessing CardSpace won’t work either, although I don’t know it well enough to say for sure.

No, what’s positively fascinating about this is that there’s a need for some fairly complex authentication mechanism, where the user is specifically asked to associate two different accounts on two different systems. The right solution almost certainly requires cryptographic tokens. I’m not sure what it will take, but we’d better think fast, because this kind of application is precipitating the end of the password authentication concept.

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.

Case in Point: Google just patched a serious security problem that allowed an Evil Web Site (EWS) to access your gmail contact list, as long as you were logged into gmail and you simply visited the EWS. The root cause: Google wanted one of its web applications to be able to integrate with your gmail contact list, and their chosen implementation was to use your browser as the transfer point. This makes sense, because your browser is likely already authenticated to gmail, so there’s a nice abstraction of authentication going on here: the application that wants to integrate with your gmail contacts simply instructs your browser to fetch it, and if your browser is already authenticated, then it succeeds.

Of course, the problem is that, if a web site can instruct your browser to fetch data, e.g. your contact list, from a remote service, e.g. gmail, then you’ve got a problem: an EWS can do the same thing behind your back. Specifically, here’s the data flow we need to carefully consider:

1. Alice visits Web Site One, which runs some code, call it Application One, inside Alice’s browser.
2. Application One then contacts Web Site Two for some information, possibly using Alice’s credentials transparently (e.g. a cookie.)
3. Web Site Two returns some data to Application One running inside Alice’s browser.
4. Application One takes this data and makes use of it inside Alice’s browser for some purpose.
5. Application One takes this data and submits it back to Web Site One.

If we allow this complete loop to take place, then Web Site One can steal all sorts of private data that Alice has stored at Web Site Two. At the same time, there are some very good reasons for allowing some of this data flow to occur. One use case is already well understood: Web Site Two might be a public information source, like Google Maps, with which a mash-up is much desired. Another use case is the contact-list example, where Web Site One would like to integrate with Alice’s private contact list at Web Site Two.

The interesting question is: how do we allow the contact-list integration without enabling wholesale private data theft? Two possible solutions come to mind:

Quarantine the Program: in some cases, it might be possible to quarantine Application One so that, once it starts talking to Web Site Two, it can no longer contact Web Site One (or any other web site) again: this effectively blocks step 5 in the data flow. This approach has limited applicability: in the contact-list example, you obviously want to do something with the contact list once it’s been loaded, and that probably involves some feature at Web Site One. There may be some edge cases where quarantine is actually useful (and doable), but they will remain edge cases.

Control the Cross-Application Data Transfer: The data transfer from Web Site Two to Application One should be explicit. In other words, in step 3, Web Site Two should know that the request is coming from Application One, should have the ability to interact with Alice directly (without letting Application One mediate), e.g. to let her select the contact she wants to use, and to explicitly return the data Alice chose to share with Application One.

I think 2007 will see an enormous rise in technologies and tricks to enable this second option: Controlled Cross-Application (aka Cross-Domain) Data Transfer. There are some existing ideas in this realm:

• the WHAT WG Cross-Document Messaging API, a work in progress not yet implemented in current browsers,
• the Cross-Domain iFrame Trick, which works in today’s browsers with some limitations, and
• Flash, which allows cross-domain requests with white-listing on the remote domain.

My feeling is that the messaging approach of the WHAT WG is the right way to go, with some cross-domain iframe hacks while the details of the specs get fleshed out. Flash is interesting, but HTML/Javascript is still the easier (and more open) way to develop web applications.

But 2007 will bring one major pitfall along with this: many folks continuing to forget why the cross-domain restriction is there in the first place. You can start to see this with people claiming that the dangerous data flow above can be broken by removing pre-existing authentication from cross-domain requests. This argument makes two large mistakes:

There are other inherent authentication mechanisms that are undetectable by the browser: many corporate intranets serve data to machines within their network without authentication, since the requests are coming from inside the network. There are also many publishers who offer site licenses to universities by white-listing their IP-address space. There’s no way for the browser to know when it’s accessing an intranet or internet service, so allowing cross-domain requests is like poking a hole in all corporate firewalls, in all home network firewalls, etc… It simply will not happen.

The browser as the focal point for authentication is a good idea: having authentication handled by the user’s browser is a really good thing. It means you can begin to abstract out authentication: Application One makes the call to Web Site Two, lets the user authenticate there and select the data to send back to Application One, and Application One never needs to understand Web Site Two’s authentication mechanism. It also means the user is in control: if Application One can contact Web Site Two without going through my browser, that’s a significant loss of control over my private data.

So that’s my prediction for 2007: a big explosion in controlled cross-domain technologies. Think of them as end-user Web APIs: assembling web application components via the browser with end-user control. It’s going to be exciting, and there are going to be enormous icebergs along the way.