Mozilla launched its BrowserID project in June as an alternative to the now commonplace practice of relying on third-party commercial Web services as “identity brokers.” If you want to offer users a non-intrusive way to establish an identity, without the overhead and security worries of an awkward off-site authorization process, it is worth taking a look.
BrowserID lets site owners offer their visitors a way to log in and leave comments or use Web applications, but one that relies only on email address verification: no per-site passwords, no centralized, external identity providers.
The Bird’s Eye View
Unlike OpenID, which associates every “decentralized” identity with a specific URL that the user is responsible for maintaining, BrowserID regards email addresses as the user’s identity. Everyone has an email address, and they already regard it as personal identifier — no extra conceptual work required.
The login process for a BrowserID-compatible site starts with the site asking for an email address and proof-of-ownership (which is called an “assertion” in official BrowserID parlance). In the simple method, in order to log in, the user’s browser and email provider will both need to support the assertion-generation process, but there are provisions for working around this. In any event, however it is generated, the browser returns an assertion that includes the email address in question, an “expiration date” (so that ne’er-do-wells can’t capture and replay logins later), and an address-ownership certificate.
The assertion is in JSON format, but it is also cryptographically signed with a private key that never leaves the browser machine. The site can verify the validity of the assertion because the ownership certificate includes the public key associated with the private key that signed.
In fact, the certificate contains three parts: the public key, the email address, and another “expiration date” — this one for the certificate itself, not for the assertion. The certificate itself is signed by the email provider, using the email provider’s key (not the user’s key). The site can check that signature by querying the email provider.
So ultimately the site checks two expiration dates and two signatures. The site verifies that it can trust the assertion by checking the user’s signature on the assertion, and it verifies that it can trust the certificate by checking the email provider’s signature on the certificate. The assertion’s expiration date is probably pretty short-term, because the user doesn’t want to stay logged in for days at a time. The email provider can decide how long the expiration date on the certificate is.
At the moment, Gmail requires users to re-log-in about once every two weeks. That would be a reasonably high lifetime for a certificate, although the BrowserID developers suggest much shorter times, closer to browser-session-lifetimes. That way, there is never a need to “revoke” a certificate, because it will quickly expire on its own. Whenever the user needs to generate a new certificate, he or she would do that by visiting the email provider. Here again, the process can vary a little bit, but generically speaking, the browser would include built-in routines to generate the key pairs needed. That is a subtle but big win; consider how successful the works-in-the-background crypt of SSL is when compared to the make-the-user-do-it approach taken by OpenPGP.
Implementation and Security
Of course, at the moment most of the world’s email providers do not perform the BrowserID certificate-generation process or signature-checking process. The protocol includes a means for secondary domain to issue a certificate with an issued-by field, and Mozilla is running a server at browserid.org to provide that secondary service.
From a security standpoint, a site owner would not want to trust just any arbitrary domain that says it can sign for a user’s email address — the secondary model is specifically designed to be trustworthy because the browserid.org domain is managed by the browser maker in question (in this case, Mozilla). The secondary service must use a suitable means to verify ownership of the email address entered. Browserid.org does this using standard send-a-verification-email techniques, wherein the verification email contains a clickable link.
On the browser-side, the protocol relies on some new client-side functionality, such as navigator.id.registerVerifiedEmail() and navigator.id.getVerifiedEmail(). The servers involved in the sign-in and certification-generation process would call one of these functions and invoke the proper browser behavior. Development builds of Firefox contain the necessary code, but it can also be implemented in JavaScript to support other browsers. Mozilla’s BrowserID team has an example site running at myfavoritebeer.org that works in Chrome, older versions of Firefox, and other JavaScript-capable browsers.
The non-native client method has its own security risks. When the site (such as myfavoritebeer.org) stores certificates and keys locally, it only has access to the browser’s HTML5 Local Storage area. That is a security wall erected to keep sites from having full write access to the user’s hard disk, but in this case it is possible that another malicious site could find a whole and tamper with the Local Storage certificates and keys. A native browser implementation will be better, because it can access more secure areas like your Firefox profile, which already stores sensitive info like passwords and cookies.
BrowserID is actually a simplification of the Verified Email Protocol, with the added benefit that it does not rely on Webfinger or other external technologies to also be implemented by the servers involved.
Naturally, even in the strongest case, BrowserID is only as secure as your email account. Leave yourself logged in to Yahoo or Gmail when you’re away from the office, and anyone can hijack your identity on a BrowserID site. But that is at least more secure than adding another set of usernames and passwords to the list of things you need to remember: if you’re not taking care of your email password, you are already at high risk.
Site Adoption
There is documentation on the BrowserID page about implementing the protocol as a sign-in option for your site, as well as basic developer documentation of the protocol itself. Perhaps the easiest way to get familiar with BrowserID, however, is to try the browserid.org service itself. I found that this can clear up a lot of easy-to-confuse parts of the handshake process. For example, several people commented on Mozilla blog posts and discussion groups asking how BrowserID copes with logging in from multiple machines. The answer is that you get a separate key pair generated on each client; with a browserid.org account, you can see all of your key pairs.
Developers are beginning to work on BrowserID test implementations for existing web frameworks; you can already test a WordPress plug-in and a Drupal module. But the process is still in development — a fact the Mozilla team is quite open about.
For those still confused about how BrowserID differs from other decentralized identity services like OpenID, a good read is Ben Adida’s blog post on the differences between the two. The short version is that BrowserID can be implemented directly in the browser (which makes for one fewer parties you as the user have to trust with your private information), and the less confusing relationship between the site you are attempting to log-in to and the party that vouches for your identity.
New authentication methods are always controversial at first, and security mavens are by their very nature skeptical. So you should expect a lot of discussion about BrowserID in the coming few months. One thing is for certain, though — an identity system that does not depend on commercial services is something that users are clamoring for, and BrowserID offers a comparatively simple implementation backed by strong cryptography.
