Mozilla

Introducing BrowserID – easier and safer authentication on the web

Security on the web is more important than ever. Almost weekly reports of exploits of information and leaks into the public make it hard for a lot of people to trust the internet.

One of the main annoyances is that every service expect us to have a login and password. As we use lots of services this means we have to remember a lot of login names and passwords. People deal with this in various ways. The most dangerous is using a simple password across different services. Another way is to not bother remembering your secure password and instead re-set it every time you come back to the site you want to access by going through a verification by email. This could also be a very dangerous approach – especially when the site you log in to sends your password as plain text rather than forcing you to create a new one. In any case, you spend a lot of time running in circles between you, the site you want to access and your email client.

There were a few ideas in the past how to work around the issue of logins and passwords. OpenID was the most ambitious one, but failed to get traction in the main market as having a URL as your identifier seemed alien to a lot of end users.

Taking the lessons and learnings from the mistakes of OpenID and other approaches Mozilla Labs is now proposing BrowserID which moves from domains and sites to emails as your main identifier. In essence, we promote the “password recovery” mechanism of the traditional login approach to your main point of access.

What is BrowserID?

BrowserID aims to offer you one single log-in to web sites and services, connected through your e-mail address (with the option to add more than one e-mail to the same account). The core idea is that you will always remember your e-mail address instead of a made-up user name or URL.

The main pillars of BrowserID are:

  • Ease of use
  • Security
  • Cross-browser implementation
  • Decentralized, web-wide validation
  • Improved experience in future browsers
  • Respecting the privacy of the user

Using one e-mail address and a master password, you only need to activate and verify your account once. As BrowserID is implemented with the Verified E-mail Protocol it has built-in security. Furthermore it offers a verification service to check against.

It works cross-browser, both on desktop and mobile, and it’s decentralized so that anyone can chose to implement it on their web site. Respecting user privacy is a very important factor for Mozilla. Therefore no information is shared with any service about your BrowserID usage (check the BrowserID Privacy statement for more information).

What makes it even more enticing in the long run is that BrowserID could be implemented natively in the web browser, for example through the URL bar, where the user could choose to log in/out. This will make it an even more secure measure against phishing and other attacks, and give end users the most consistent and reliable experience.

Try it out

If you want to try an example, you can go to the TextChannels web site, create a BrowserID account and sign in with it.

After you have created a BrowserID account at TextChannels, you can go to our other test web site and see how easy the experience is when you have a BrowserID account.

Here is a video explaining the procedure:

How to implement BrowserID

If you want to use BrowserID in a web site, you have to go through three main steps:

  1. Enable BrowserID
  2. Identify the user
  3. Verify the User’s Identity

Enabling BrowserID is quite easy: simply include the BrowserID JavaScript in your web page. Then add an event handler to a sign in button in your web page. This button will be used to identify the user. When that is done, you need to verify that user’s identity on the server-side. This can be easily done through the BrowserID verification service.

Here’s some complete sample code:

<img id="sign-in" src="https://browserid.org/i/sign_in_green.png" alt="Sign in">
 
<script src="https://browserid.org/include.js"></script>
<script>
  document.getElementById("sign-in").addEventListener("click", function () {
    navigator.id.getVerifiedEmail(function(assertion) {
      if (assertion) {
          /*
              User has successfully selected an email
              address they control to sign in with.
          */   
      } else {
          // The user is not logged in
      }
    });
  }, false);
</script>

When you successfully received the assertion, send a request to https://browserid.org/verify with two GET parameters. For instance:

$ curl "https://browserid.org/verify?assertion=<ASSERTION>&audience=mysite.com"
{
  "status": "okay",
  "email": "lloyd@mozilla.com",
  "audience": "mysite.com",
  "valid-until": 1308859352261,
  "issuer": "browserid.org:443"
}

How does it work?

If you want to delve deeper into the flow and inner workings of BrowserID, check the How BrowserID Works article.

BrowserID is experimental – help us

Please note that while Mozilla Labs is putting a lot of work and thought into BrowserID, its current state is experimental. That means that it is not recommended to use in any real-world production web sites at this moment.

BrowserID is something Mozilla believe to be very beneficial to the web, but we need your help! Please try BrowserID out as a user, play around with the code and give us feedback! We are working on making this a great asset for users and developers alike, and any input we get will make it easier and faster to reach that goal!

17 comments

Comments are now closed.

  1. Mardeg wrote on July 21st, 2011 at 01:40:

    I noticed Mozilla is not a member of the Kantara Initiative in my link.
    Is there a plan to integrate this project with that?

  2. Thomas Svenson wrote on July 21st, 2011 at 03:55:

    I find the BrowserID initiative very interesting and plan to test it out for a few of the sites I am working on.

    I build my sites using Drupal and already on the 15th of July a module for BrowserID was released for it. Can be found at http://drupal.org/project/browserid

    Open source once again proves it is the bleeding edge :)

  3. zub wrote on July 21st, 2011 at 06:00:

    Do I get that right that the browser holds the private key? I’m not sure to fully understand the “how it works” page, i might have to go read the actual code

  4. askdksd wrote on July 21st, 2011 at 06:56:

    Way to go, Mozilla, woo! You guys rock, thanks for this.

  5. Adrian wrote on July 21st, 2011 at 08:45:

    Not sure this is the right place for it (Bugzilla?) but just a slight bug I picked up on. When registering for the first time the sign in and cancel buttons then did nothing until i closed the window and clicked ‘sign in with Browser ID’ again. Using Chrome 12/Windows 7.

    1. louisremi wrote on July 21st, 2011 at 09:38:

      I cannot reproduce your problem, using Chrome.
      If you are able to reproduce it, you can report it on bugzilla, using the “identity” component: https://bugzilla.mozilla.org/enter_bug.cgi?product=Mozilla%20Labs
      Thanks

  6. Anonymous wrote on July 21st, 2011 at 08:48:

    How can I use BrowserID on a page which can’t use third-party scripts? Any way to handle it via a first-party script communicating with browserid.org at arm’s length?

    1. JPF wrote on September 26th, 2011 at 04:23:

      can anyone tell me how to view, hidden email address on someones profile.. pleaseee …

      1. Robert Nyman wrote on September 27th, 2011 at 00:12:

        Not sure if you mean you want to see the different e-mail addresses you have registered? In that case, sign in on any web site utilizing BrowserID and then go to https://browserid.org/manage to manage your account.

  7. Stephanie Daugherty wrote on July 21st, 2011 at 09:19:

    I like what I see so far, but I see several lingering problems and concerns that have to be addressed.

    First, In order to truly “own” my own identity, I have to be able to reassert control even if my email provider goes away or goes rogue, and quickly update my identity to a new address. Otherwise, you have the same exact problem as OpenID, where maintaining your own domain is necessary for full control of your identity.

    Second, account recovery needs to be somewhat disruptive. It has to cause enough inconvenience that I know whether recovery has been performed – that is, if someone gained access to my email account, and recovered my BrowserID credential, the password should have changed, and I should be locked out until I do a recovery. It’s not clear right now whether this is, or is not the case for now.

    Third, browserid.org is still a single point of failure and compromise. Even with appropriate security there, (and knowing how Mozilla secures web applications, I’m not terribly concerned), there’s also the issue of compromise under legal force. BrowserID has the potential to be a gold mine for a government investigator looking to gain access to a suspect’s accounts, and in the US, under current laws such as the PATRIOT act, the authorities could force Mozilla’s cooperation. The only defense there is to make such cooperation physically and/or logically impossible. I don’t see that yet.

    Granted, these are the same flaws as OpenID, which I still use, but we don’t need another authentication “standard” that repeats OpenID’s mistakes – even though the implementation is different, the same flaws are very much present.

  8. Justin wrote on July 21st, 2011 at 11:27:

    Love it!!

    Was just looking into OpenID for a small project in Go.. I haven’t seen a lib yet for Go, and implementing it is a bit more than I want to tackle right now.

    Nice, simple, easy, awesome!!
    Thanks Mozilla!

  9. Robert Nyman [Mozilla - post author] wrote on July 22nd, 2011 at 04:47:

    Thanks for all the nice comments!

    Mardeg,

    Regarding the Kantara Initiative, I’m not aware of any current plans, at least, for Mozilla to join that.

    zub,

    Hopefully this explains it:

    The browser locates the private key generated in step #2 and moves it and the certificate from temporary session storage into the user’s BrowserID key-ring. The user now has a valid certificate from gmail stored in their browser which they can use to generate assertions proving their identity.

    Adrian,

    If you prefer, you can also report a BrowserID issue at GitHub.

    Anonymous,

    You can do it on your own server. Please read about how to at the bottom of the BrowserID for Developers page.

    Stephanie,

    Thanks for raising important issues – great feedback!
    Regarding your third point, you can host it all yourself, making it completely decentralized from browserid.org. More info about self-hosting at the bottom of that page.

    1. Stephanie Daugherty wrote on July 22nd, 2011 at 09:17:

      Robert, thanks for the response, That leaves my remaining big question – what happens when my email provider goes rogue, gets hacked, gets served a warrant, or just plain goes away? How do I find out this has happened (discover that someone has generated another key for my email address in the rogue, hacked, served warrant cases), and redirect all my accounts to a new identity after this happens?

  10. Robert Nyman wrote on July 22nd, 2011 at 13:46:

    Stephanie,

    Great questions. I have no answer right now, but I’ll ask the BrowserID team to reply to that.

  11. Dan Mills wrote on July 22nd, 2011 at 14:50:

    Hi Stephanie,

    Thanks for the great comments!

    You are right that if your email provider goes rogue, is hacked, or coerced, it can impersonate you. That’s inherent to federation, as I think you pointed out as well.

    One important point is to allow you to run your own identity provider. By moving the API to the client and focusing on inherently decentralized identifiers (email), we’re making it so that relying parties will support the long tail by default. I think it’s unlikely (though it is possible) for general-purpose sites to only accept emails from one domain, for example (something that is relatively common with OpenID).

    I would be interested to hear any other ideas for how to at least detect when this kind of impersonation is taking place. Maybe something involving more parties to make collusion harder? I think, however, that there needs to be (and I think there already is) a moderate level of trust in email providers. After all, you are already trusting them with your email. But we’re definitely interested in hearing other ideas–jump on our IRC channel or join our mailing list!

  12. Régis wrote on July 18th, 2012 at 01:29:

    I have just discovered BrowserID today (sorry, I have not followed Mozilla news for some time).

    I think one of its biggest problem is its main advantage. Some end-users don’t want to share their identity. And some don’t care.

    On the contrary, web-masters want to know as much as possible.

    And who implements authentification on web sites? Webmasters do.

    Bottom line: Facebook connect is here to stay.

    But BrowserID can kill OpenID…

    1. Robert Nyman wrote on July 31st, 2012 at 08:40:

      Well, let’s hope that people will be more aware about the information they share and will be more careful about that. At the end of the day, it’s about choice and options.

Comments are closed for this article.