Mozilla Offers Alternative To OpenID

Orome1 writes "Mozilla has been working for a while now on a new browser-based system for identifying and authenticating users it calls BrowserID, but it's only this month that all of its sites have finally been outfitted with the technology. Mozilla aims for BrowserID to become a more secure alternative to OpenID, the decentralized authentication system offered to users of popular sites such as Google, Yahoo!, PayPal, MySpace and others."

Comments

What, me worry?

[Anonymous Coward]

I have an RSA SecureID token for logging in to my company VPN and we all know how rock-solid RSA is.

Re:What, me worry?

[Surt]

Locks, and security in general, are intended to raise the cost of unauthorized access beyond the utility of that access. Success by that measure is effective security.

Useful Links

[weezel]

This submission looks like typical content farm / blogspam junk so here's some useful links instead:

• The BrowserID main page: https://www.browserid.org/
• Mozilla Identity Team's blog: http://identity.mozilla.com/
• Source Code: https://github.com/mozilla/browserid

Re:Useful Links

[icebraining]

I think the JS part is true, but the centralization is only temporary until there are Primary Identity Authorities (which would be mostly email providers, from what I can tell).

http://lloyd.io/how-browserid-works

Re:Useful Links

[Tacvek]

The way it is supposed to work (eventually)
1. User clicks sing-in link on website.

2. Website calls a Javascript function that is implemented by the browser. They pass in a callback function that takes one argument (described later).

3. The user selects an email address from a list in the browser, or chooses to add a new email address.

4. The browser checks a with the email provider (via http, and a well known location (like robots.txt or favicon.ico)) to verify that they support BrowserID. We will assume the email provider does support BrowserID. The response includes a public key for the Provider, and a provisioning url.

5. The browser opens the provisioning URL in a hidden iframe.

6. The provisioning page requests the email address from the browser.

7. If the user is already signed in goto step 10.

8. The provider indicates that the user is not signed in, and tell the browser the URL of the sign in-page, which the browser shows to the user.

9. The user signs in as normal.

10. The provisioning page asks the browser to generate a cryptographic key pair.

11. The browser passes the public key to the provisioning page, which passes it to the provider's server, which signs it (with a short expiration time) , replies with the signature , which is passed back to the browser.

12. The browser creates an assertion, which is the domain name of the site the user is trying to sign into, the email address, and a short expiration time, signed with the browser-generated private key. The assertion also includes the signed public key.

13. The browser passes the assertion into the callback, which passes it to the website's server.

14. The website's server extracts the email, fetches the provider's public key, much like the browser did. The server validates the assertion includes its domain name, and is not expired, and was signed by the included public key. It also verifies that the public key is not expired. If so, it extracts the email address, and uses it to fetch the email provider's public key. It uses that to verify that the email provider signed the public key found in the assertion.

15. The user is considered signed in by the website.

How this looks to the user
In the most common case, the user is already signed in with their email provider, so the user sees themselves clicking on the login link, picking their email adress, and that's it. They are signed in.

How this currently works
Currently there is no browser support. There is a centralized location that provides a JavaScript polyfill and associated website allowing the system to be used without browser support. Both the provider's provisioning page, and the Relying website's page must use this polyfill, and this must be one one centralized location, since both would need to use the script from the same site in order for this to work.

Currently there are also no email providers that provide this support, so a central provider is used as a fallback. This provider must be in a centralized location, since both the browser/polyfill-site and the relying party must agree on the fallback provider. This provider does the only thing it can to verify ownership of a third party email address, which is sending a standard challange email to the address, which the user will access and reply to.

Simplicity

[improfane]

BrowserID is pretty simple. It's basically a single Javascript function that a website can call in the browser. This example on github shows the function that is called. The clientside code is then free to make requests to the server for a specific authentication mechanism, making it very flexible. The Server code just validates the username/password.

Personally, I think it's simpler to understand than things like OpenID which are convoluted and not standardized from the user point of view. Where is the standard account management protocol for OpenID?

An older Slashdot article on BrowserID for reference: http://www.yro.slashdot.org/story/11/07/15/1216222/Mozilla-BrowserID-Decentralized-Federated-Login

Not heard of Enigform but will look into it!

Re:Simplicity

[Korin43]

Oh I don't know, how about when Asa Hitler...sorry, Dotzler, declared that business users didn't matter and they changed the release schedules for Firefox even despite the public outcry against it?

How dare they not let users make marketing decisions for them!

In fact it was so publically derided that Mozilla have back-pedalled and announced an "LTS" version of Firefox specifically for that purpose.

How dare they.. uh.. listen to their users.. Wait what are we angry about again?

Re:Simplicity

[hairyfeet]

We may not be able to brand him a flip flopper (and the Nazi ref is just tasteless and pointless) but we CAN label him a dumbass and obviously not the right man for the job when he doesn't even bother with a single survey of his actual CUSTOMERS before pulling such a bonehead stunt. Moz may be "free as in beer" but if they don't have users they can't get Google or anybody else to pay for their search results so they had damned well better listen to their users. As we saw here recently the figures show FF has been in a solid death spiral since Version 4, with it shedding more and more users by the month as they get tired of the bullshit. I myself started looking for alternative at V 4 when it started sucking on AMD CPUs and bailed on V 6 for Comodo Dragon. I still have FF installed and keep it updated as well as try each new version but so far its still sucking on AMD CPUs and the CPU spiking and RAM usage, especially on the Zacate dual cores and the older low power singles and multicores like the Phenom e series really sucks.

So instead of wasting their resources and time trying to replace a project that frankly nobody really used in the first place, how about listening to your damned customers and fixing the fricking browser, how about that? Remember the ORIGINAL mission statement, the one you used to get us off the suite, to "build the fastest and lightest standards complaint browser" remember that? Ever since Google released Chrome its been a "ohh me too!" fest at Moz and frankly it sucks. the UI sucks, the performance sucks, and I'd argue its because they are trying to jam shit on there Gecko was never made for, like flash plugin isolation, which at least on AMD causes FF to suck as much as twice the resources playing an SD video as any of the Chromium based.

And finally please fanbois, or those that have "perception bubbles" as I've been told to call you by someone who was offended at the word fanboi, please don't trot out some benchmark because i can trot out one that says the GeForce FX was actually a great Dx9 chip. Of course we all know now that they were writing to the bench which made the benches worthless but IRL all you have to do is use what I call the "Hairyfeet normal folks test" where you fire up a tool like process explorer that will give you the complete resources of a program then send the browser through the basic sites everyone goes to, YouTube, FB, Yahoo Mail/Gmail, and check the resource usage and you'll see for yourself that FF don't stack up so good.

So please moz devs, quit trying to be the saviors of the web and fix your shit first, okay? there are a hell of a lot of us that would be happy to come back to the fold if you'd just quit trying to make a bad Chrome ripoff and go back to making a small fast standards compliant browser we can DIY customize with extensions. Nobody has an extension framework as good as yours, nobody. some come back moz, quit all this crap that has nothing to do with your core business and get back in the business of making browsers because as the numbers show the way you are going now is NOT the correct way to go. kinda sad you are talking about "hiding" the LTS on some back page somewhere just because you are afraid that everyone will dump the main branch for LTS, doesn't that smack you witrh a cluebat that you are on the wrong path?

What is wrong with OpenID?

[brunes69]

- It is widely adopted among many providers
- It does not share any of your information cross-site unless you allow it
- It works

Why do we need yet another standard? I do not see anything in this article, on browserid.org, or anywhere else that breaks down why Browser ID is superior.

Also, I don't see Google Chrome adopting this, since Google backs OpenID, and I don't see Microsoft adopting it either. So really this is going to end up a Firefox only scheme that will never gain enough penetration to make sites want to go to the effort to implement it.

Re:What is wrong with OpenID?

[icebraining]

I think the main differences are that it uses email addresses instead of an URL (which people don't "get" as being your identity token) and it doesn't give the authorities full power to access your accounts (since the private key for authentication is stored on the browser).

Re:What is wrong with OpenID?

[cdrnet]

An email address is exactly what I do NOT want to provide to every second website where I just need some simple customization/profile. And where I do provide an email address, I always use a unique address (essentially allows me both automatic organization into folders but also to get less than 1-2 spam mail per year, simplify by blacklisting aliases which either leaked or obviously have been sold to some spammer (happens usually about a year after some web service/sites shuts down)). This works very well with OpenID, at least with decent neutral providers.

But then I guess BrowserID does not primarily target tech people...

Mozilla eh?

[AbRASiON]

I'll wait for BrowserID v9 in 6 months

Different problems

[improfane]

I think BrowserID and OpenID solve slightly different problems. BrowserID standardized the process of you logging in through your web browser while OpenID is about authenticating yourself through some authority (be it a server controlled by you or some third party). So that's a user-website interaction for BrowserID or website-website for OpenID.

They could actually be used together, any service that accepts OpenID logins could expose a BrowserID interface too.

Re:and how does it work?

[icebraining]

It stores a private key in your browser that you need to auth yourself (transparently to the user).

Re:Simplicity = BAD

[dkf]

https://www.browserid.org/about
No password?? Are you kidding me??
The moment I saw that 3rd step, I just.... I'm speechless. What the fuck?

When you dig into the details past all the JS crap, it's actually just a variation on client-authenticated SSL. I'm not 100% sure what exactly is being asserted in the client's identity (before checking back with the issuer) but it most certainly does work, and it should be fine provided the private keys remain locked outside of the grasp of even the browser JS. That is, the private key must provably not ever leave the browser; if anything can make that happen, it's insecure whatever the developers think.

Browser based... ugh D:

[shish]

a new browser-based system

The only problem I have with OpenID is that it's so web-centric it's a pain in the ass to implement for native apps. Could we please have a distributed ID system that *can* use a web browser, but doesn't *require* one?