Introducing BrowserID: A better way to sign in

They seriously need to work on their communication skills. It took me a good 15min to figure out what this thing actually does. And I'm still not sure I got it right. OpenID failed because it was too complicated for mere mortals. This, I fear, may be too confusing. At least form the way it's presented.<p>After reading the protocol spec, I have a somewhat better understanding of this. If I got this right, this is basically what this does:<p>* asymmetric crypto authentication in the backend.<p>* control over email address == authentication.<p>* allows a trusted third-party to authenticate the user. This could be a user or a web service (like browserid.org?).<p>* falls back to regular email authentication we see every day.<p>I'm still unclear how you can securely verify email ownership thru cryptographic means. Anybody care to explain it?

What I'd really want to see is public-key authentication for website.<p>Let me upload my public key when I create an account on a website, and let the browser interact with my ssh-agent to authenticate.

My first ever programming project (I was 11) was basically this (edit: from a UI perspective, not under the hood), in PHP. I had no idea what I was doing, the architecture was questionable and at this point decentralization and OpenID were new and hot. It flopped horribly; it would have been a nightmare had it taken off, but it was fun.<p>My flow was basically this: website links to <a href="http://my-site/login?to=http://site.com/authenticate" rel="nofollow">http://my-site/login?to=http://site.com/authenticate</a>. User logs in against my MySQL database with an email I verified and a password. If successful, I generate a "ticket" number, my site makes an HTTP post to <a href="http://site.com/recevive" rel="nofollow">http://site.com/recevive</a> with md5(ticket number + secret key) and the user's details, and then the user is redirected to <a href="http://site.com/authenticate?ticket=12345" rel="nofollow">http://site.com/authenticate?ticket=12345</a>. Site.com verified the ticket using its API key and stuck it in its database. When the user hits site.com/authenticate, it looks it up by ticket number and has that person's details.<p>Obviously a terrible idea for a number of reasons (MD5, the race condition between the user and the ticket, and the reliance on my shared server being up) but my 11-year-old self thought it was pretty cool. Just thought I'd share.

One huge problem: Email address != identity.<p>I should be able to change my email address (and/or email hosting provider) without changing my identity on a bazillion sites around the internet. Facebook got this right from the beginning. Google is sort-of getting this, although the chasm between Google Accounts and Google Apps Accounts makes this really messy.<p>Really this product should be called BrowserEmailAddress, not BrowserID. It doesn't serve identity.

How is it different from OpenID, apart from it's not decentralized?

Am I the only one who kind of wishes we never went down this "let's fix authentication!" rabbit hole? It feels like we've just replaced one problem with another.<p>Now, instead of simply having to remember what username/password combination I used, I have to remember which (if any) OpenID provider I used, how much information about myself does said provider expose, and how to merge my accounts when I inevitably end up choosing the wrong provider and create a duplicate account on the site.

More at <a href="https://browserid.org/" rel="nofollow">https://browserid.org/</a>

Say you're signed in to BrowserID already ... is there anything that would stop an attacker from being able to log you into some other BrowserID website without your knowledge or consent? With login reduced to two mouse clicks, it seems like a well-crafted webpage could log you in wherever it wanted. If that were the case, a CSRF-vulnerable BrowserID webpage could easily be exploited at a large scale.

BrowserID is a good first step, but ultimately as a website owner I'd much rather authenticate with Twitter/Facebook, since it makes it easier for me to figure out who the user is/ask them to share with friends.<p>Identity is cool, but Facebook is winning the 3rd party connect game right now because it offers websites syndication, which is more valuable than just authentication.<p>I'd love to see a BrowserID that can <i>also</i> grant permissions to Facebook, Twitter, etc.

This looked great until I got to certification. At this point I think they've just re-invented X.509 and added browser/Javascript integration.<p>Why not have a new way of using X.509 in the browser? I'm not talking about client side SSL certificates as they are at the moment. I mean that on login to your mail provider the browser will automatically generate a keypair and get a certificate either from your mail provider or from a third party which has verified that you own the email address in the traditional way. This certificate will contain a Subject of mail=me@example.com, Issuer of either CN=example.com or CN=trustedverifier.com. Then the browser can just present that certificate as normal to destination.com, and perhaps only on request (so the user can choose whether to "log in" or not). If the issuer matches my email address domain then destination.com will fetch the public certificate of example.com to verify. If the issuer matches trustedverifier.com then destination.com will already know whether it wants to trust it or not and have the public key if it does.<p>This does seem to be what the article describes, only the article has more optional elements and re-invents some of the cryptosystem rather than re-using X.509.

How is this any different than current single signon systems, like Microsoft Live, Yahoo, Google, Facebook Connect.. I mean sure maybe this is open and anyone can run their own but lets not forget users dont care at all about that..

So, it's basically a traditional single-sign on system? Is that right? Like, in the old days, I integrated one of my products with AOL. You could click a link and it would automatically sign you into my product using you AOL Screenname and Password (behind the scenes, AOL would verify that the screenname and password are correct and my app would create a new user in my database).

I hope that one of these services is on the user's side, so much that the ID isn't enough for, say, advertisers to track users over different sites. And how graceful is it for versions of IE that aren't 'recent'?

What's the advantage over openid?

Can someone explain what makes this a <i>browser</i> ID? I don't get it...

Somehow I find WebID (<a href="http://www.w3.org/wiki/WebID" rel="nofollow">http://www.w3.org/wiki/WebID</a>) more appealing. There are already countries that give their citizens SSL client certs.

Email != authentication<p>Websites providing a disposable email address are mainstream - even hotmail allows you to create them these days.

Thought that popped into my head. Instead of having separate passwords for different sites, now you are trusting your email provider to be absolutely secure (with that one ultra-secure password you are using, right?).<p>So if a BrowserID user were to ever get their email service compromised, it's keys to the kingdom.<p>IMO, I think this needs a rethink.

This is just another web based open sign-in. Why did they tie this to email, of all things?<p>My immediate thought was that a browser-based ID implementation would let you keep secure credential on the computer, saved by the browser, up to and including pics, profile, etc. In other words, take social credentials native.

Do people really consider OAuth2 difficult to implement?<p>Also, not trying to knock BrowserID or say that it'll never work, but due to browser compatibility this is still probably 5 years off before I'd begin using it. From what I can gather it requires postMessage which alienates IE7 users.

Interesting that in the demo video he used in-browser Gmail vs. using Thunderbird.<p>I realize its nitpicky, but figured for a demo like this Mozilla would use the opportunity to showcase all their offerings in the workflow.

This seems to encourage using the same credentials everywhere which I think most agree is a "bad idea." If BrowserID is compromised, the attackers have access to all the sites where I use browser id, right?

This is full of fail. Your email address is not your identity. I must be able to change my email address without having to change my identity.

I like this idea, and I hope mailinator supports it.

can't see it taking off only because it solves a problem that 99% of internet users do not know exists. I have never had a regular, average, non-tech internet user say to me 'you know what is a real pain in the ass - signing up for web applications'. Most of those users only ever signup for a handful of applications, and are using oauth for everything else (twitpic etc.)

Does that mean this is as secure as the user's email provider? What if I have an AOL email and AOL gets hacked?

Whilst I understand and really like the non-tied in aspect of it, I'd probably implement some sort of facebook/twitter/google account authentication alongside of it.<p>Reason being is that, it too is just another authentication service that I'd rather users not have to make the effort to sign up for.

By what mechanism does BrowserID require RPs to respect the valid-until field?

Was that... was that a blink tag?

anyone else notice the video is recent enough to have google+ enabled?

And then you get phished for your one password.

You can try it live at <a href="http://textchannels.com/" rel="nofollow">http://textchannels.com/</a> . I like it , it's pretty simple and neat. Easier than oauth login.

so, its an easier way for sites to track users?

I interpreted this as OAuth + Gravatar... is that the gist?

I don't want to see another browser-specific feature from mozilla. As mentioned here several times it doesn't seem too different from openId and it's for mozilla!<p>seemed pointless to me.

When I tried to sign in on the demo site I got a 502 Bad Gateway error. This isn't an encouraging sign.