Introducing BrowserID: A better way to sign in
identity.mozilla.com
identity.mozilla.com
After reading the protocol spec, I have a somewhat better understanding of this. If I got this right, this is basically what this does:
* asymmetric crypto authentication in the backend.
* control over email address == authentication.
* allows a trusted third-party to authenticate the user. This could be a user or a web service (like browserid.org?).
* falls back to regular email authentication we see every day.
I'm still unclear how you can securely verify email ownership thru cryptographic means. Anybody care to explain it?
When your browser and email provider both support BrowserID:
1. You log into e.g. gmail.
2. Your browser generates a keypair and sends the public key to gmail.
3. Gmail signs your public key and sends your browser a certificate saying "this key is owned by whoever@gmail.com".
4. You click "sign in" on some site (e.g. Hacker News) that uses BrowserID.
5. Your browser sends Hacker News an message saying "my user is whoever@gmail.com", that is signed with the private key generated in step 2.
6. Hacker News looks at the "gmail.com", grabs gmail's public key (the one that signed your public key in step 3) and verifies the signatures.
Hacker News now knows that you control whoever@gmail.com.
The process is described fairly well (diagrams and everything) at http://lloyd.io/how-browserid-works
> BrowserID is a decentralized identity system
BrowserID effectively links identity an email service provider, and while I realize that not everyone shares their emails with Google, a vast majority of people still does. That's not that much of decentralization, is it? Practically speaking.
(edit) Added practically speaking... and ease up on that downvoting, distinguished HN comrades. Non-natural post scores hurt my feelings.
Or, in other words: if you don't trust Google, don't use gmail; that someone else chooses to do so doesn't make this system less secure for you.
Decentralization leaves the possibility of that situation changing open. That matters.
(Or, less philosophically: there was a time that everyone and their dog were on Internet Explorer. I think we're all glad that we didn't close the door to browsers other than IE.)
It's difficult to imagine an authentication system that doesn't have some kind of centralized mechanism for making sure identities aren't duplicated. In this case, delegating that to a combination of two existing technologies (DNS for the domain, then email for the username) that are open, well understood and easy to implement seems appropriate.
What's the alternative? Using some kind of pseudo-GUID and then maybe a derivative of the Paxos distributed consensus algorithm to decide if it is to be trusted? I'd imagine there would be a good number of PhDs in that approach before a system like that would be close to being ready for actual implementation.
This system seems just about as decentralized as is practical. If you disagree I'd be very happy to hear alternatives.
You are right - theoretically this could work. But it would pretty much take a "boil the ocean" approach to make it work.
Browsers would need to implement a secure (private) keystore, and presumably some way to sync that to other browsers.
A whole new standardized authentication flow would need to be created, which wouldn't be the same as the existing certificate-based authentication (which no one uses anyway)
[1] http://en.wikipedia.org/wiki/Simple_public_key_infrastructur...
[2] http://en.wikipedia.org/wiki/Public_key_infrastructure#Web_o...
This particular ocean should be fairly easy to boil with a browser extension for all popular browsers.
A BrowserID (like an email address) is memorable and secure, but not decentralized (it's centralized in DNS).
A cryptographic key is decentralized and secure, but not memorable.
Systems that are memorable and decentralized, but not secure, don't address these use cases at all.
(And then there's Namecoin[2], which is a fascinating development, but not likely to see broad adoption in the near future.)
[1]: http://en.wikipedia.org/wiki/Zookos_triangle [2]: https://en.bitcoin.it/wiki/Namecoin
Besides, the fact is that most websites already use email, so BrowserID is not any worse than the status quo.
I don't completely understand all this yet, but it appears that what distinguishes the system from one that is entirely trusting of client-side JS code, is the fact that the e-mail provider signs user's key. That means that we must be able to get the e-mail provider's public key somehow. There is supposed to be no central authority, so we must get it directly from the e-mail provider.
Your link includes this line:
> 4. Public key(s) for gmail.com are attained from a well-known location on their servers (specifics TBD).
This service is absolutely necessary to get BrowserID working, but they haven't figured out the specifics yet. I think they need to get beyond that "TBD" pretty darned quick.
Properly implemented, OpenID looks like this to the user: http://springpadit.com/login
And something like this for the average developer: https://github.com/omab/django-social-auth
Have a Google or Yahoo account? Your email address is your OpenID. Of course nobody is going to manually enter an OpenID URL. Why would they need to?
"Properly implemented", OpenID looks like http://ikiwiki.info/ikiwiki.cgi?page=index&do=edit : a choice of common OpenID providers to help users who don't understand OpenID, an option to use an arbitrary OpenID, and an option to use a username and password.
Properly implemented, BrowserID looks like one big shiny "sign in" button, and yet it still supports any service the user wants to use, and better yet no third-party service at all. Seems like a big improvement to me.
And all OpenID providers have different attribute exchange protocol extensions. If you use them, you can effectively allow only those you have tested.
If my brain had a replay button, it would say:
* Ok, what if I have multiple accounts? Ahh, nice.
* Hmm it would be cool if it worked like LastPass, where you get great security and only one password to remem... ha, nice, it's very similar!
* Email verification? ....yep, check.
* Can you lock the browser so that nobody can just use your browser to sign in? (No direct answer, but I assume so. Or will be this way soon.)
* Open source? Great.
I didn't really expect any technical answers. But they did mention the blog and there's got to be some good posts coming soon. Subscribed.
The question I do have: why would I use this over something like LastPass which already has plugins for every browser and device most people will ever care about?
They don't verify e-mail ownership through crypto means - they use the fact that e-mail is identity.
Basically, your mailhost (or a proxy, like browserID) holds your public key, while your browser holds your private key. Now, when you authenticate against any BrowserID auth site, you simply sign with your private key and provide the e-mail address. Since the browser stores both, that's a trivial interaction.
The site then verifies your signature with the mail host. (That's where the asymmetric crypto comes in)
At least that's how I understand it - their explanation is indeed a bit cryptic. Hope they clean it up.
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.
I just don't get it. I've seen it in HN comments for a few days now, but I fail to understand how 'this.' relates any new information. Reply indenting already tells me you are referring to an antecedent post. (A specific post in fact.)
Am I missing something, or is this just a new web fad I'm not savvy too? (Second option is not entirely unlikely...)
That's essentially what this is... with a verification service and web based UI to help bootstrap it.
From that document: "destination.com retrieves Alice's public key from mailhost.com by using a webfinger lookup over SSL."
So it looks to me that the system's security depends on the attacker not having compromised DNS such that the relying party's query of mailhost.com is intercepted. Depending on the implementation doing this "over SSL" provides some additional security over unchecked reliance on DNS, but given how frequently keys roll, it may not be that much in practice.
http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-c...
The interface is ugly and cumbersome for the non-technical (even in Firefox) and I don't think it's used very often, but I know that MIT issues certificates to students which identify them to all MIT's web applications, as well as third parties like the Apple and Dell student discount pages.
Email addresses are typically controlled by a third party, so it doesn't make much sense to me that they should be equated with identity. Would you equate your identity with your IRL work address?
On the other hand, private keys are held only by the person whose identity they represent. They are a better way to represent identity because they do not rely on third parties.
It's discontinued though unfortunately. Although there are still people out there making it work with newer versions of Firefox: https://grepular.com/FireGPG_on_Firefox_5
My flow was basically this: website links to http://my-site/login?to=http://site.com/authenticate. 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 http://site.com/recevive with md5(ticket number + secret key) and the user's details, and then the user is redirected to http://site.com/authenticate?ticket=12345. 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.
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.
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.
Really this product should be called BrowserEmailAddress, not BrowserID. It doesn't serve identity.
It's very similar to the countless existing services that rely on email for identity... you'd just have to verify ownership of the new email address (usually through a confirmation email).
At the very best this technology offers considerably less value to websites and more hassle to users than Facebook or Google. And it's about 5 years too late.
And how is this different than the current situation? Nearly all web sites require an email address. With BrowserID, you at some point confirmed ownership of that email address, so you could continue to use it to login, then change when you're ready.
"At the very best this technology offers considerably less value to websites and more hassle to users than Facebook or Google. And it's about 5 years too late."
Tell that to users who a) don't have Facebook accounts or b) don't want to use Google or Facebook with their identity. Far more people have email addresses than Facebook or Google accounts.
The question is whether a BrowserID identity is as useful as one of the established identity providers. You start out with a chicken-and-egg problem; websites won't consume BrowserID if users aren't using it, and users won't use it if websites aren't asking for it. What will overcome this Catch-22? Techwise, the dependence on email seems less compelling than Facebook or Google auth.
Maybe BrowserID can rely on mass distrust of Facebook and Google. I'm not sure that's sufficient though - especially with Google.
google auth is just one provider of the same identity as browserID-- an email login. so, imo, browserID is a strict improvement, in that it is more seamless than google auth in regular usage (leveraging the browser as the user agent), and works with more providers.
(One work-around would be to use an disposable e-mail address service and redirect your emails as needed.)
What a weird double-standard. A feature of email (that you can have several, and you can change which one you use) is a failure, and a failure of Facebook (that it's one site, forever) is a feature?
We're all familiar with ways to migrate from one email address to another. If/when you leave Facebook/it disappears, how will you migrate your identity then?
My Facebook account is an identity first and foremost. People do not typically have multiple Facebook accounts (a TOS violation). If that account goes away, that identity goes away.
You might make an argument that websites should allow you to aggregate multiple identities (Facebook, Google+, MS, Yahoo, etc) into a single account, or that there should be some sort of an identity provider that creates an aggregate identity across all those services. To an extent some of these websites are already doing something like this peer-to-peer - Facebook is an OpenID consumer, for example. Maybe sometime in the future this will be a big issue. But right now it isn't, and email-as-identity is already an annoying problem.
Now imagine 5 years ago you said "My Friendster account is an identity first and foremost."
On the other hand, email is already known to be an unstable key for identity. And the "market" for identity providers is a lot more mature than it was 5 years ago. Besides, what if Friendster had established itself as a public identity provider 5 years ago? Maybe we would be using Friendster instead of Facebook today. Who knows.
Would be happier if there was only one company that provided email service and you were only allowed to have one address? That's essentially the situation with Facebook.
You're free to apply whatever constraints you like to your use of email. An email address is as unstable an identity as you make it.
Two close friends of mine were the #2 and #4 employees of Friendster. I seriously considered becoming #3. I had a pretty good outsider's view of the early years.
Yeah, they screwed up the scaling pretty badly. But even worse they screwed up the business - after you set up your profile and looked around, there wasn't much more to do (unless you were single and looking). People were already using Friendster as an identity (emailing links as a "you mean this person, right?"). Maybe if they'd opened an API and enabled third-party apps, they could have maintained this position. It's a big "what if" but it can't be dismissed outright.
the team is in talks now about cooperation with another mozilla labs project centered around 1-off email generation for quick and easy anonymity with sites
In a practical "on the internet sense," your email really is your identity (maybe SSN or name would be a better description; you can change it, but to do so is catastrophically disruptive). After all if you can't be contacted you really can't be identified, and the universal way of contacting someone online is through email.
Now, you should definitely try and provide some redundancy (store multiple email addresses, long living sessions, whatever) and make your anonymous/unauthenticated/drive-by user experience stellar. But when push comes to shove if you can't send them a "forgot your username/password/open-id/samoflange" email, you've lost that user.
(anecdote: I've had the same primary email for >7 years)
Literally the same thing, here.
I'm just assuming it works this way, as passing the password along would defeat the security of the system and make you more vulnerable.
I literally don't see a major difference here, except that now we're using email instead of whatever bullshit identifier you could have used with other OAuth providers (e.g., your Livejournal username, your Facebook account, etc., etc.)
If I'm wrong, I would love to be enlightened.
The major difference is it's totally irrelevant to the site (relying party) what provider you're using. The site doesn't need a login page with a facebook button, a twitter button, a livejournal button, etc., it just needs a "sign in" button.
Even email isn't safe, unless all the OAuth providers validate the email. Does Twitter allow me to change my email address to "president@whitehouse.com", and then return that to OAuth consumers as my email? I don't know.
There's too many things ways to shoot yourself (or someone else) in the foot.
1. Primary Identity Authority. This is a host (i.e. the one in your email address) that supports BrowserId. This is fully decentralized.
2. Implementation Provider/Secondary Identity Authority. For now the site has to choose one to trust, but once your browser has support it becomes the IP, and when your host becames a PIA there's no need for an SIA.
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.
Passwords make the world less secure.
So we need to replace them with something. And that "something" has to be secure and easy to use.
Turns out that this is a difficult problem to solve, so we keep trying. I agree that OpenID is not exactly the perfect solution, but it doesn't mean that there is no problem to solve.
At least with normal un/pw you need to request a password reset from the website.
I don't think we should be tying logins to email.
BrowserID supports password reset requests, which can be built into the browser
email is the single most user-recognized signifier of identity we have on the internet today. tying identity to anything other than email just seems silly
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.
I'd love to see a BrowserID that can also grant permissions to Facebook, Twitter, etc.
I do not trust either of these companies, or have a strong attachment to them.
If they want to support BrowserID then they can - as username@facebook.com or username@twitter.com
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.
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.
As a site operator, you don't need to choose which company you're going to accept as an auth provider, or have a login page with lots of icons on it; you just have one button that says "Log in".
Having in-browser support for this kind of thing seems like a plus, too.
I've implemented OpenID.
I run my own Open ID server.
I've implemented Shibboleth (and lived!).
I know that Yahoo is an open ID provider, and I think Google is too, but when I'm presented with an old-style (URL) OpenId login I don't have a clue what to enter to use either my Yahoo or Google account to login.
Yes, I know that now most login forms provide easy links to use Google or Yahoo to login. The point is that entering the URL is confusing because no one knows what their OpenID url is, and it isn't standardized in anyway.
The situation is so bad that the OpenID providers had to develop a way for users to enter their email addresses, and then the client performs a discovery request to find their URL.
It's a good point though, the fact that email addresses have to be somewhat memorable/human-readable by nature is a good thing for BrowserID.
I would be willing to bet Google and Yahoo made their OpenID URLs hard to remember because they already had single sign on products that they wanted in the limelight preferentially over OpenID. However, cursory support of OpenID made them both look like supporters of open standards even if their implementation (hard-to-remember URLs) doomed it to underuse.
But then, Google, Facebook and Twitter have reduced the friction for identifying all over the internet, so Mozilla is kind of arriving late to the party.
BrowserID, on the other hand, fundamentally uses distributed identity via public/private key crypto, and only involves a (single) third-party service as a crutch to allow browsers without native BrowserID support to handle BrowserID, so that sites can adopt this immediately rather than waiting for browser support.
Websites providing a disposable email address are mainstream - even hotmail allows you to create them these days.
So if a BrowserID user were to ever get their email service compromised, it's keys to the kingdom.
IMO, I think this needs a rethink.
But anyways, my impression from reading the page was this is not just used as a password reset scenario but as a general login method.
Which if you agree with, leads us back to the scenario where authentication & authorization lies solely with the email account, which if compromised is the single point of failure.
I would appreciate it if someone were to help point out what flaws there in this line of thought rather than a straight downvote with no explanation.
In effect, any site that offers a password reset via email is already using your email as your identity.
Yes, because e-mailed password reminders are keys to my kingdom already.
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.
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.
I realize its nitpicky, but figured for a demo like this Mozilla would use the opportunity to showcase all their offerings in the workflow.
(Unless you meant "BrowserID" the protocol.)
At least that's how I understand it.
Presumably you could sync them up if you really wanted to, but it would be an awful user experience if that was mandatory.
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.
- No need to use an oauth library (just 1 GET request)
- Oauth provides access to user data on the provider, while browserID provides no data. Less anxiety for the users.
- No request_token/access_token pairs
- In the future, the user will (hopefully) be able to change his default browserid and as a developer you just don't care.
It's one of the defining pieces of consciousness, and essential to the human experience. So, as programmers, we make a deliberate choice to enable this functionality for end-users in most internet applications (like email, IM, social networking, and discussion boards) by displaying a token belonging to you (and only you) next to what you're saying and doing. This can be a username, email address, phone number, picture, etc. This particular spec is a more convenient way of establishing your ownership of a token used to identify you.
You can choose to use sites (like 4chan) which don't reveal this information publicly. But if you sign your posts, or indicate in any way that you are the same person as a previous poster, you are establishing an identity which 4chan is tracking and revealing to the world. There is no conversation without tracking.
Whether or not the sites you use choose to identify you, however, they know you by the IP address you are coming from; they have to, in order to send information back. Tor can mitigate this (if you change exit nodes with every request) by hiding your path from A to B within a cryptographically secure mass of data, but if the random number generator determining the amount of time to wait before forwarding your packets is broken, that's blown too.
IP addresses change, so if I want to correlate you between your ISP's DHCP leases (or between your multiple internet connections - Starbucks, home, work), I'll set a cookie. This is how when you clicked "reply", Hacker News knew it was still the same person who logged in with "ukaszg/hunter2".
Tracking is essential to civilized conversation. To fight tracking itself is to ask that the entire Internet become 4chan and that nobody assume the same identity from post to post. I hope this isn't what you mean.
--
Tracking makes you nervous because
a) computers exhibiting human behavior is kind of creepy b) sometimes, companies choose to violate users' expectations of what will be done with the information they've correlated
But you can't take this information away from them while still using their services. You can refuse to use services which violate your expectations, you can demand better, and I encourage you to.
But ultimately, these services have to pay the bills and make a profit. I could be wrong, but I'm going to take a wild guess and say you wouldn't pay for Facebook; I'm going to go even further and say that you would be offended at the idea of having to pay for Facebook.
Well, Facebook's employees want to feed their children and buy cars and houses and video games and TVs just like you. And Facebook's owners and investors want to get rich. If these objectives aren't met, there won't be a Facebook.
So instead of taking your money, they take what they can guess about what you will buy, and charge advertisers for it. Advertisers, in turn, can show you products which you won't scoff at paying for, and eventually some less speculative cash enters the equation.
You cannot avoid tracking. But if you want the companies tracking you to conform to your expectation that your data not be used to sell you stuff, you're going to have to pay them. Rackspace email is $2/mailbox/month. There are no ads.
A system based on pseudonyms allows anonymity through the creation of arbitrary new identities. With care, such a system can also support reputations for a given identity.
seemed pointless to me.