Mozilla's BrowserID (single sign-on for the web) is live
github.com
github.com
* federated (like OpenID)
* open standard (like OpenID)
* no passwords / no typing / no memorizing (e.g. like FB Connect)
* possibility of browsers providing an integrated experience (technically possible with previous solutions, but no browser has done this so far -- in the case of OpenID for a very good reason IMHO)
* anonymity/choice of identities (like OpenID, definitely unlike e.g. FB Connect)
* no exposure to identity provider (this is unlike any existing solutions; if you log into a site, your OpenID provide, Facebook, Google, etc. will know which site it was; not with BrowserID!)
Check out Dan and Ben giving a nice demo of the BrowserID user experience: http://www.youtube.com/watch?v=6x45Nt1fOMM. No passwords, no typing, and anonymity where desired.
If you're interested in the nitty gritty details, Lloyd explains the cryptographic assertions that actually let sites verify your identity: http://lloyd.io/how-browserid-works
(EDIT: format bullet points)
That's not quite true, is it? The documentation says I need to verify the user's identity by calling e.g. browserid.org/verify…
- https://github.com/mozilla/browserid/wiki/How-to-Use-Browser...
The problem is, OpenID will still require you to remember your OpenID provider's URL. (You could also be with one of the half a dozen or so big identity providers, and then every site gets to implement the "Nascar sticker" style icon banners. Like, uh, I don't know, news.ycombinator.com for instance ;)).
On top of the OpenID URL, a lot of sites also want a way of contacting the user via email. So that's another bit of info that you're going to have to enter when you sign up for the first time. What's interesting is that your email address almost certainly identifies you already anyway.
So why not just use email addresses instead of the URL, and API calls instead of those hideous redirects to establish identity? It's not too hard to see how you would end up with "verified email" as a core identity concept, and that any of the mechanics described by OpenID aren't really useful.
There is no reason that your browser can remember a unique username and password for every site you wish, but not a single OpenID url. Or that it can fill in username and passwords across wildly-varying-markup sites, but not in the much-more-frequently-identical OpenID fields. At absolute worst, the OpenID experience can be 100% identical to the Username/Password experience, but no browser I've seen has even done this trivial implementation, much less a more seamless one.
FB Connect requires you to memorize your Facebook password. It also requires you to have a Facebook account. BrowserID requires neither an "account" or a password.
Technically there's 1 password (your BrowserID login password), not "no passwords". :)
(Though of course you can have multiple identities (email addresses) all associated with the same BrowserID account, so as you increase the number of identities, I suppose your passwords-per-identity approaches zero... ;) )
Unfortunately that might be what prevents this or http://webid.info/ from getting traction. The big guys wouldn't like losing that data, and OpenID/OAuth already do the job well enough for them.
A comparison WebID/BrowserID can be found here: http://security.stackexchange.com/questions/5406/what-are-th...
As currently implemented, it appears that if the Primary Identity Authority or Secondary Identity Authority keys are compromised, then all accounts for which that authority is trusted are also compromised. This enables accounts to be compromised en masse, rather than individually. It would seem that by de-centralizing authentication, browserid centralizes security.
Ok, so revoke the compromised certificate. If you "trust" browserid.org and do assertion verification on your own servers, how are you notified of the compromise and key change? Conversely, if you offload assertion checking to browserid.org and they go down, will users really understand why they can't log in and your site is "broken"? You could use CRLs and OSCP, but now you have another thing to get wrong in individual sites' assertion verification implementations.
Another interesting side effect of PIA or SIA key compromise is that an attacker could now create accounts and impersonate users, not just access existing ones.
It would also appear that due to the omission of a nonce, assertions are vulnerable to replay within the validity window.
I think that authentication is broken, and commend attempts to fix it. I'm just not sure that all the added complexity of browserid really buys us anything, and instead enables new attacks that previously weren't feasible.
Until secondaries go away, Mozilla seems like a very competent and trustworthy organization to have in charge of browserid.org, IMHO. Much better than even Google. It's great to see that even the branding on browserid.org is minimal.
My guess is that, concerning nonces and revocation, they didn't consider the current situation (OpenID, OAuth for login, etc.) any better. BrowserID doesn't seem to do away with the strong advice to run HTTPS for such sites.
However I'm a little disappointed that they tell you to add it as a blocking (synchronous) JavaScript include in the head of your document.
lloyd
I know, I know, it's 2011, but still I feel it's unnecessarily limiting.
Just drop in a few lines of code and you have single sign-on.
Let us (the BrowserID team) know if you have any feedback on the experience.
My biggest criticism is the lack of a concretely defined spec for how the Verified Email Protocol works, if one wanted to implement it directly, rather than relying on browserid.org.
Based on the code in the repository, the protocol seems relatively straightforward. But, as it currently stands, it'd be difficult to implement it based on the paper spec alone.
Anyway, nice work on BrowserID. I'm excited to see where its headed.
Firefox already stores passwords in a local database and it wouldn't be that hard to automatically log users into sites.
The method they describe here requires every web site be changed and requires cross-domain JavaScript to be enabled such that browserid.org will know which websites you visit. You _could_ place include.js on your local domain to avoid this issue. However history has shown that sites will tend to just cross-domain link to googleapis or yahooapis.
Additionally, this is yet another web authentication method that should probably be handled at a lower level in the stack -- either the HTTP protocol, transport layer (TLS) or perhaps in the future, by using IPSec.
That's why.
The user stores the keypair and certificate locally.However I fail to see how this is useful: no sites use it, because no users use it.
Let's not muddy the waters. Use openid. No excuses.
In its current form, BrowserID requires the user to do the email-verification dance once for each email address they want to authenticate as, and from then on they can just pick it from a list instead of doing the dance yet again.
In its ideal form, once the BrowserID API is implemented directly in browsers and webmail systems (instead of the shim at browserid.org), the user doesn't need to remember anything: they click "sign in" on the web-page, the browser brings up its standard 'pick an email address to authenticate as' dialog (populated from all the webmail sites the user has logged into), the user selects one from the list, and off they go.
As far as OpenPhoto, we're pushing BrowserID because we think it's a much better authentication system than something like Facebook Connect. It's open, distributed and secure. We do have FB Connect plugins for OpenPhoto but we believe that defaultly using BrowserID is the right thing to do.
http://blog.theopenphotoproject.org/post/13914931003/the-int...
It seems to me the opposite is true. What is your source for this?
"NOTE: You may choose to validate assertions on your own server. While a bit more complicated you can reduce your dependencies on others. Refer to the specification and the source for the reference validator."
So while it's easier to use their server, it appears it is entirely possible to implement without it. Perhaps in a few weeks, we will see some good implementations. As I understand, the main advantage over OpenID is that instead of needing a <username>@<someopenidprovider> login, people can simply use an email address as their login. If all email providers supported OpenID, there would be little difference, but that has not happened (yet).
How does it compare to client-side certificates?
How so? As far as I know, the only mandatory information is the OpenID identifier (the URL you need to input to authenticate). While more information can be exchanged, that's completely optional and up to the user. For example, MyOpenID always asks what "persona" - if any - you want to send when you authenticate.
BrowserID is no better: you need to input your email address.
- validating the signed authentication token you get back from calling the authentication function. As user "decentralized" points out, this is just a convenience; your service can do this itself if you don't mind getting your hands dirty with crypto code.
- Serving the JS shim for user-agents that don't implement navigator.id.getVerifiedEmail() natively. Once browsers implement this function themselves, and webmail systems can tell the browser that the user owns a particular email address, this won't be needed either.
Hope that changes sooner than later.
I've implemented it on OpenPhoto and absolutely love it.
I am all for simple log-in procedures, but as a web site owner, I want to be really sure, the email at least exists to prevent a bit of spam or low-quality content.
I guess it's possible for somebody to set up a website that will sign absolutely any token anybody offers them, but (a) as a website operator, you can tell that the token "foo@example.com signed by example.com" is different from "foo@example.com signed by evil.com" and (b) you could always have a blacklist/whitelist of entities you trust to verify BrowserIDs.
But Facebook could benefit from this. Maybe not at this early stage, but the way you log into Facebook is using your email account. That's exactly the step BrowserID wants to make easier.
Not minified. Come on Mozilla, you did the same thing with the (rather large) Open Web Apps library. Minification is required. You are Mozilla, you should know this. YUI Compressor takes a few seconds at most.
That's just the license header that's not stripped. I agree, that's a bit draconian. lemme see if I can fix that for you.
lloyd
Quite a bit too experimental for me to register I'm afraid
Probably not a coincidence either, my bank used to rely on client side certificates but gave up after, I guess, an insane amount of support calls.
and then, those certified authorities still fail to secure themselves
it certainly made a lot of sense but in reality its not that good
It's like SSH, not HTTPS.
CAs are only useful to match a cert to a domain and/or known organization, or inside an organization to make sure the user has a cert signed by the org itself.
But how do you know you're copying your key to the right site and not some fake? Answer is, of course, you don't, so you need something else. And it's not stronger than the weakest link..
Authentication using HTTPS is the same theory as SSH public key authentication.
I can see a slight potential to trick the user into using a rogue authority. Imagine the evil email address is somehow tailored to a site the user is expected to log in to, in a way that makes it look like the "right" selection for that site, in the BrowserID dialog. I can't think of an explicit example right now, but when you allow untrusted parties to inject text into trusted dialogs, there are often many possibilities for trickery.
At best, we will still need some way of filtering out junk from the identity list.