Hacker News new | past | comments | ask | show | jobs | submit login
Introducing BrowserID: A better way to sign in (identity.mozilla.com)
364 points by joeshaw on July 14, 2011 | hide | past | favorite | 180 comments



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.

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?


Ignifero described what happens when your browser or email provider don't support BrowserID.

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


Read through your link, and here's just an observation -

> 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.


"decentralization" doesn't mean "forced decentralization". Anyone can register a domain name and have their own email at that domain, so anyone can create an identity. And ignoring the transitional bits in BrowserID, eventually that identity gets controlled entirely by the public/private keys in the user's browser.

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.


Sure, I understand that of course. I am just saying that practically speaking this property is not going to matter much in the world where everyone and their dog is on GMail. It is certainly nice to have though.


The last numbers I saw put Gmail at under 10% of email account marketshare. Hotmail and Yahoo both had much bigger shares.

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 can have fully decentralized identities quite trivially: just create a public/private key. No consensus algorithms required. With browsers now supporting synchronization features to connect the browsers on all systems used by a single user, such a system could actually work quite well now, without the usability issues it would once have had.


This is a variety of SPKI[1], right? I was thinking of a conventional PKI approach, with an adapted web of trust to verify identities [2].

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...


Huh? Browsers support client SSL certs today, but for some reason nobody uses them except intranets.


"boil the ocean"

This particular ocean should be fairly easy to boil with a browser extension for all popular browsers.


Zooko's triangle[1] in action:

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



A system that assumes that everyone is on GMail will tend to ensure that everyone is on GMail, whether or not that's a good thing.

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.)


Uh, GMail users are a minority. Besides, the system is decentralized - the fact that most people can choose the same server is not a problem of the system.

Besides, the fact is that most websites already use email, so BrowserID is not any worse than the status quo.


This is very thought-provoking. One observation:

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.


Something like DomainKeys Identified Mail (DKIM).


That sounds like such an obvious and fairly simple solution. Thanks for the explanation!


Why would you want your email provider to support BrowserID? I'd consider it invasive for my email provider to do anything different to interfere with the email verification process for another site.


I don't follow you, what's invasive/interfering about it? You & your browser can decide whether any of the steps of this process actually happen.


The proposed BrowserID standard specifically suggests that the browser should ask the email provider to validate the email, and only fall back to the usual email-me-a-link validation if the email provider doesn't "natively" support BrowserID. I'd prefer to always go through email-me-a-link verification (ideally with some kind of crypto involved), rather than involving the email provider in any way other than SMTP and IMAP.


Can you link me to where you're reading that? I don't see anything like that (but I've only skimmed the documentation).


See the teaser at https://browserid.org/primaries , and the documentation at http://lloyd.io/how-browserid-works .


I've read it more thoroughly now, but I'm still not sure where you're coming from. You'd rather use a secondary identity authority, even when a primary is available? Or are you saying you'd like to require a full send-me-an-email-and-i'll-click-on-a-link verification every time you log in to a relying party?


Wow, I had exactly the opposite experience. Tons of thoughts popped into mind as I watched.

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.


Exactly, I think most users of LastPass or 1Password had the same thoughts.

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?


And let's not forget that you can add any site to Lastpass, while with BrowserID you can add a site that already implemented it. That sucks.


How did OpenID fail (it's widely used)? How is it complicated for the user?

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


That site fails terribly at supporting OpenID: it only supports four authentication providers, and doesn't allow a user to enter an arbitrary OpenID URL.

"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.


There are legitimate reasons to whitelist OpenID providers, especially if you are dealing with $$ or want to minimize support costs.


Why do you think a "properly implemented" OpenID site should allow the user to use any authentication provider? The relying party site is trusting the OpenID provider to authenticate its users. Wouldn't sites with real security requirements want to vet providers before trusting them?


Exactly right.

And all OpenID providers have different attribute exchange protocol extensions. If you use them, you can effectively allow only those you have tested.


I don't see the OpenID here. I see them restricting me to only 4 third-party sites. Since there doing that, using OpenID or using each third party's system makes no difference. OpenID's supposed to be decentralized, but how do I log in with http://stevearm.com?


I don't think it's widely used. The average site that doesn't want to provide their own username is using Facebook nowadays. Stack Overflow etc. seems to be the only bigger site that uses it, and it's kind of a mess over there.


Do an online poll and ask people "Do you know your openID" vs "Do you know your email". Users are trained to use emails for login, and that's a significant investment already.


That was a brief failure of communication when OpenID was new.

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?


Read the "Verified e-mail protocol" thingy instead. The blurb the link on HN points to is indeed completely useless.

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.


i thought the video demo was pretty clear for the consumer perspective-- to a user, they click sign in, tell a site what email they want to identify with to that site, don't have to make a specific login to that site, and the browser handles everything.


They give you a token, you do a GET request to browserid.org with it and get the user's email, that's all. The user has to register their email with browserid.org first.


Wasn't one of the benefits that you don't need to rely on a third party service?


The third-party service handles the case where the user's browser doesn't handle BrowserID natively, which makes it possible to adopt this service without waiting for user's browsers to catch up.


I believe you will definately rely on one (of many possible) 3rd parties.


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.

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.


that's a really cool project at 11 years old, both in terms of your idea and what you can actually accomplish! off topic, but when i was 11 i had a c64 and basic and couldn't dream of talking to another computer unless i saved my program to the tape drive and had my mom drive me to my friend's house to load it on his c64.


What I'd really want to see is public-key authentication for website.

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.


Have you read the spec? https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol

That's essentially what this is... with a verification service and web based UI to help bootstrap it.


A good way to check if does the right thing is to make sure it does not depend on the security of DNS. Is this the case? (I'm still trying to find out.)


BrowserID implements https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol

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.


BrowserID references the verified email protocol as an inspiration, but they specifically removed the webfinger bits.


Apparently, it does not do what I hoped it would. Assertions are about ownership of an email address, not about control of the private part of a key pair.


This already exists, but the UX is terrible and there's a chicken-and-egg problem in getting it fixed in every (deployed) browser.

http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-c...


Yeah, even using them over at GitHub (well, pushing with Git over SSH in general) has proven to be a rather steep learning curve for a lot of people. But hey, it's being widely adopted there, so that's a step in the right direction for this.


Something like this already exists. Your browser can already identify itself with a certificate.

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.


Dartmouth does this as well, and I agree the interface sucks in browsers. Especially since most browsers will gladly show expired certificates for you to choose so you have to manually prune your list.


Same here. That's basically what I suggested here: http://news.ycombinator.com/item?id=2677140

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.


They don't equate with identity but give a way of communicating with the user using a different channel. In a world of passwords this allows that password to be reset.


That's in a way what BrowserID is. Except all sites share one public key, and your browser holds the private key. (Thus replacing ssh-agent)


FireGPG has something built in to do this. It's called gpgAuth. http://getfiregpg.org/

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


Will you and the website owner each verify the key fingerprints? What I'm getting at is it's a hard problem to solve, because users want it to be quick and easy. But that often works against the stated goal of security.


I don't see why the website would need to verify my key fingerprint. Verification is needed when you care who a key comes from. For typical websites, they don't need to know who I am. They only need to know enough to recognize on subsequent logins that I'm the same person who provided the key at account creation, and the key itself has all they need for that.


This... A million times this. Where do I signup?


This. Perhaps ssh+http is the solution.


Where is 'this.' coming from? Coding syntax?

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...)


It's just for added emphasis. It's the contraction of roughly "this is the correct answer".


Thanks for enlightening me =)


This is the new +1


It is popular on sites like reddit. It basically means "I agree".


if you're interested in ssh-like functionality and http, I just wired browserid into my shell server for in-browser logins: http://benctechnicalblog.blogspot.com/2011/07/browserid-in-b...


One huge problem: Email address != identity.

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.


I agree that email address != identity, but nothing would stop a site that uses BrowserID from allowing a user to change the email address that they use on that site.

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).


My thoughts exactly. I actually respect the thinking process which is: rather than invent something from scratch (some new user ID), let's use something that everyone is already familiar with: a traditional e-mail address.


Sure, every website can implement this flow, and users could could go to every website they've ever logged into and update their email address... assuming it all works properly even though they might not have access to the old email address anymore.

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.


"Sure, every website can implement this flow, and users could could go to every website they've ever logged into and update their email address... assuming it all works properly even though they might not have access to the old email address anymore."

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.


Fast forward another ten years. Do you really think typical websites will still ask people to create usernames and passwords? I predict that the current trend of "offload that crap to Facebook/Google/BrowserID" will continue. Even BrowserID.org makes that assumption.

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.


facebook, i agree, makes sense for an assertion of your public, real-name identity. there will always be sites and situations where i do not want my real name associated with what i do there.

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.


I understand the sentiment but simply because a solution doesn't cover all use cases (users must be able to change email addresses) doesn't mean it can't be usable. Also, we constantly use services were you cannot change your email address because that's how the system identifies you, so this dependency of email addresses isn't new at all.

(One work-around would be to use an disposable e-mail address service and redirect your emails as needed.)


aka add a level of indirection, just like the solution to every other problem in computer science. :)


> Facebook got this right from the beginning.

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?


Email is a tool whose value lies primarily in my ability to communicate with other users. Many people (including me) have several email addresses that we use for different purposes. That an email address can be used as an identity is something of an afterthought, and doesn't really fit into the "have multiple email accounts for different communication purposes" paradigm.

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.


"My Facebook account is an identity first and foremost."

Now imagine 5 years ago you said "My Friendster account is an identity first and foremost."


I'm not saying that identity management won't be an ongoing problem, especially if large repositories of identity rise and fall with fashion.

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.


> On the other hand, email is already known to be an unstable key for identity.

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.


Downvotes? Wow, that's unnecessarily harsh.

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.


In the literal sense that you are not your e-mail, yes email != identity.

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)



Alas, email address has become the online analog to the venerable SSN.


OTOH, facebook id != identity, neither is twitter username. There will always be some id that you won't be able to change. But you are right that email is a bad choice, and i was surprised they give away the email address to developers. They should provide the browserid.org ID only.


it's a compromise move-- the reason most sites today rely on email, fb, or twitter is that it's a way to 1) contact the user, and 2) tell/help the user to tell his/her friends about something.

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


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


This lets users sign in with an existing email address, so they don't need any new sevice or identifier to remember. It's decentralized; Mozilla has a service for web developers for convenience, but any site can implement the protocol itself instead (or use another provider). And it's designed to let browsers handle the login flow in the future, simplifying login and account creation for end-users.


Most of the oauth services I used allowed me to create an account with ... an e-mail and a password.

Literally the same thing, here.


Isn't one of the advantages of this system is that your password doesn't get stored by the website? Just some type of token? If their database gets stolen or leaked, they shouldn't be able to hash attack your password and gain access to it since it's not there.

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.


You still have to enter your e-mail and a password into the BrowserID popup; and with OAuth, the sites using it didn't store your password either.

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.


browserid.org ("the BrowserID popup") is just a way to bootstrap the system. The idea is that browsers and email providers will support this protocol and browserid.org will be totally unneccessary.

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.


It's a step forward. There were security issues. Some sites used "name" as the user identifier, because obviously nobody on Facebook shares the same name (sarcasm).

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.


It actually is decentralized, in the sense that anyone can implement a BrowserID provider.


Anyone can, but from the looks of it, a site chooses to trust one at a time.


There are two separate things here. Using the terminology from http://lloyd.io/how-browserid-works , you have:

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.


I'm wondering if it's at all possible to integrate this with OpenID, and how this interacts with previous Mozilla Identity projects to make your identity a part of the browser chrome. It all seems rather tangential to their other efforts, rather than coherent with.


I certainly hope it isn't possible to integrate this with OpenID. If it is, sites will just continue relying on OpenID, and treat this as a weird special case, rather than a superseding technology that gives the user control without requiring a third-party provider.


Looks like they just re-implemented something that's already been done by OpenID... Mozzila wanting their share of the user pie?


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.

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.


Did you read the article? This is an attempt to fix all those issues you list.


BrowserID only fixes those issues if it ends up as the only game in town. Otherwise, it's simply going to be tacked onto the end of a daunting list of other OpenID / BrowserID providers that users will have to choose from.


So now when your email address gets hacked, ALL your usernames and passwords to every website are also hacked!

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.


by tying all your logins to email, you're left with only one account that you can focus on keeping secure and un-hacked (or a few, as BrowserID allows for multiple emails). The BrowserID is also in talks about support one-off identity generation via the browser, bypassing email on sites which you don't want to identify with.

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


You see, passwords suck. Big time. They are extremely vulnerable to brute-force attacks, people forget them, people write them down on post-it notes, and people use the same password on every single site. Not to mention that the website has to store your password securely, and not every website has amazing track record doing that.

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.


I never said that there wasn't a problem. I'm simply saying that the solutions we've come up with so far have not yielded a net gain. If anything, the site owners that I know who have incorporated OpenID / Facebook Connect / etc. into their sign up / login forms have said that they have to answer more questions from users having login issues than ever before.


I like this approach specifically because it doesn't have to replace the traditional sign-in process. A BrowserID sign-in button can be added to a traditional sign-in form without any fuss, and users can either use it or ignore it. And if the BrowserID sign-in is broken, then no worries, the traditional sign-in form works anyway.




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.


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.

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.


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.

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 want to link my Facebook with anything else. Nor do I wish to link my Twitter to that.

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


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..


As a user, once your browser and email provider support it, it's single-click login (and signup), without any redirects.

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".


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).


Your description is too vague to generate an answer to your question.


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?


Some people think that using URLs instead of email address in OpenID was a big mistake.

Having in-browser support for this kind of thing seems like a plus, too.


Email addresses are something that people are fairly familiar with when it comes to signing in. Trying to explain why URL's are used instead of email addresses in OpenID is difficult when you are dealing with a non techy user.


To this day I still do not understand how this inane argument happened to be the single thing that killed OpenID. How is ‘cody.my-open-id-provider.com’ more confusing as a login than ‘cody@my-email-provider.com’? Hint: it’s not. I’m not one for conspiracy theories, but the whole URL-versus-email argument against OpenID seemed like the excuse various people used to put a nail in OpenID’s coffin when they didn’t like it for other less defensible reasons.


I'm a reasonably competent web user.

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.


What bearing does the fact that Google and Yahoo chose shitty hard-to-remember OpenID URLs have to do with the overall fact that OpenID uses URLs for authentication? That’s like saying using email addresses for authentication is a terrible idea because mail administrators can assign really hard-to-remember email addresses. The solution is simple: set things up so they’re not hard to remember. Again, there is no reason why your OpenID login can’t be ‘name.my-open-id-provider.com’.

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.


Google/Yahoo/etc. could have given you a memorable OpenID if they wanted.

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.


There seems to be an implied trade-off between a usable system and a distributed system. Most users and most developers at this point will go for usable.

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.


OpenID fundamentally argued that you should trust a third-party authentication service. Not too long ago, Mozilla tried implementing OpenID directly in the browser so you didn't have to trust any third party, but that represented an afterthought in the OpenID ecosystem.

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.


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


It's designed so that the browser can interact directly with the authentication protocol, saving steps for the user. This grew out of Mozilla Labs' "account manager" project, which had a protoype UI you can see here: http://hacks.mozilla.org/2010/04/account-manager-coming-to-f...


Somehow I find WebID (http://www.w3.org/wiki/WebID) more appealing. There are already countries that give their citizens SSL client certs.


Here's a quick WebID to BrowserID comparison: http://lists.w3.org/Archives/Public/public-xg-webid/2011Jul/...


Email != authentication

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?).

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.


The idea is that you would use this in situations where you currently would offer a "reset password via email" option - since this means you already treats control of the email address as identity.


Wondering why I was downvoted for pointing this out.

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.


If an email account can be used for password reset, a compromised email account can be used to log in. Since much of the internet already works this way, the proposed system has a neutral effect on security, while making things easier for users.

In effect, any site that offers a password reset via email is already using your email as your identity.


I actually use this as the primary authentication mechanism for sites I rarely/occasionally visit... password reset at every login!


> you are trusting your email provider to be absolutely secure

Yes, because e-mailed password reminders are keys to my kingdom already.


This is just another web based open sign-in. Why did they tie this to email, of all things?

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?

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.


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?


The same could be said about OpenID and OAuth providers like Twitter, Facebook, Google, etc. The idea of having a centralized authentication provider is definitely not a new one. There are many advantages to using 3rd party authentication providers. The biggest security advantage 3rd party auth providers have is that they do security right and often they implement their authentication service using a commonly defined protocol. Many websites that choose to roll their own systems make many security mistakes and many people use the same credentials on many sites. So if any website is not secure authentication a user's login information is likely compromised across multiple websites because people generally use the same credentials.


There is a large distinction here - the provider (in the video, BrowserID.org) would have to be compromised, as only they have your credentials. This is quite a bit different and more secure than using the same credentials with many different providers, because in that scenario, the weakest of any party could get compromised and that way compromise all parties.


In addition to that, since the ID provider does not get any sort of information about which websites you visit with your ID, it would be impossible to know where exactly the ID is in use.

At least that's how I understand it.


Once this is supported by browsers and email providers there is no "BrowserID" to be compromised, your email provider would have to be compromised (which already gives attackers access to all the sites that you use that email on).

(Unless you meant "BrowserID" the protocol.)


Isn't that what happens when someone compromises your email too?


Interesting that in the demo video he used in-browser Gmail vs. using Thunderbird.

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 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.


It's not that simple. They authenticate against your Account at Browser ID. I would assume you can go into Browser ID and add / remove email addresses from your account which makes it even easier when you change your email. Now you don't have to visit 20 different sites to update them.


Is there some sort of account ID other than an email address? It looks like the email is all that gets sent to the website (although I didn't read deeply enough to be sure). If you change (add new, remove old) your email address at browserid.org then revisit a site you authenticated to before, what happens?


Indeed. Ideally, the site would end up with the user's public key, and optionally their email address; they should use the former as the primary key in their database, and the latter as an easily-changed property.


That would be nice except I think that you will have different keys for different browsers, and for different machines.

Presumably you could sync them up if you really wanted to, but it would be an awful user experience if that was mandatory.


The implementation at browserid.org returns the email only. So there's no way to change the email without visiting all the sites you've registered in using browserid.


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?


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


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.

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.


The intention seems to be that browserid.org is temporary, just there so that this can work until it's supported by browsers and identity providers directly. Once that is achieved, there's nothing extra to sign up for.


Sorry, the video didnt make that clear - not even slightly.


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.


The password only applies to browserid.org, not the browserid standard. Native browser implementations won't involve a password, just a public/private key.


You can try it live at http://textchannels.com/ . I like it , it's pretty simple and neat. Easier than oauth login.


can you explain why this is easier than oauth?


- No need to register your application with browserid.org

- 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.


thanks, I thought you meant it was easier _as an end user_ and could not see why.


The implementation using browserid.org, to an end user, will not get any easier or harder than OAuth or any other third-party service. On the other hand, a browser-based implementation could simply bring up a browser notification saying "Authenticate to example.org using your email address?", to which you could click "yes".


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


Not really. It's a way for a user to prove to a site that they control an email address.


sounds like tracking to me


Ok, but only In the same way that typing in a username and password on a website allows them to track you.


Various forums already verify you own a certain email account when you sign up. Basically everyone does to send your account information or their marketing stuff. This isn't new.


To have a conversation with someone, you have to uniquely identify them, and correlate all the words they've said as coming out of their mouth and not somebody else's, then put all these words (which you've identified as being part of the same sentence) together into meaning. As you get to know someone, you correlate all these meanings into a mental model of the person, and use this to guide how you interact with them. People who can't do this are considered mentally ill.

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.


I agree with almost everything you just said, with one exception: while sites often need to have a notion of identity for their users, that identity should not correlate with the identity used on any other site, or with other alternate identities on the same site, unless the user wants that correlation.

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.


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!

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: