
Mozilla's BrowserID (single sign-on for the web) is live - waterside81
https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on-Your-Site
======
philikon
A lot of questions here revolve around how this is different from OpenID and
single sign-on solutions like Google Accounts or Facebook Connect. Here's a
rough list (may be incomplete or inaccurate by now; while I work for Mozilla,
I'm not involved in this project):

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

~~~
m_eiman
_no exposure to identity provider_

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…

~~~
thristian
The documentation also says "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."

~~~
Groxx
Doesn't that make _you_ the identity provider, who you must identify yourself
to? That sounds pretty similar to running your own OpenID server.

------
kogir
I'm pretty sure I understand how this works, but please correct me if I'm
wrong.

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.

~~~
stephank
I think the intention is for the primary to be your email provider. So if they
become compromised to that extent, then I wouldn't feel very safe about my
email account in the first place. Pretty much all of my credentials everywhere
depend on that.

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.

------
MattBearman
I like the idea of this, seems like a much better solution than Open ID, and
I've never been a fan of sign in with Facebook/Twitter/Google/etc.

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.

~~~
lloydhilaiel
the include file is about 4.7k minified and compressed. You don't need to
include it in head, that's lame. we'll update the docs.

lloyd

------
moonboots
I'm not seeing how BrowserID differs from the standard email verification sign
up. I went through the sign up process (enter email, click link in
verification email, enter password, sign in with password). I also read
Mozilla's 'really short version' explaining browserid
(<https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol>) and will give
the longer version a shot.

~~~
RandallBrown
I think you only have to do the email verification one time. After that,
you'll be able to log in to any BrowserID site without entering anything.

~~~
tricolon
Indeed; I believe it authenticates your browser (or perhaps only your browser
session?) across all BrowserID-using sites, drastically cutting down on the
number of times you'd have to type in a password.

------
skrebbel
Maybe I'm stupid, but the linked article gives me the idea that JavaScript is
requirement to be enabled to allow log-in. Is this true?

I know, I know, it's 2011, but still I feel it's unnecessarily limiting.

~~~
jmathai
At the moment the BrowserID team provides a Javascript shim but the goal is
that it will be supported natively in the browsers. The shim if a fallback
(which applies for all browsers atm).

~~~
thristian
Even if the API is supported natively in the browser, it's still a JavaScript
API, so you still need to allow the website to run JavaScript so that it can
call that native method.

------
ww520
This looks interesting, simple UX for user and simple to implement for
developers. I'll give it a try in my next project.

------
jaredhanson
For anyone interested in using BrowserID authentication from a Node.js app,
Passport (which I developed) has a BrowserID module:
<https://github.com/jaredhanson/passport-browserid>

Just drop in a few lines of code and you have single sign-on.

~~~
vthunder
Very cool! I didn't know you'd added that.

Let us (the BrowserID team) know if you have any feedback on the experience.

~~~
jaredhanson
I'd say the experience is quite easy, especially when using
browserid.org/verify for verification.

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.

------
dhx
Why?

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.

~~~
gcp
Because you don't need to create an account on each and every site you visited
(together with decoding a similar number of CAPTCHA's, etc)

~~~
icebraining
And more importantly than decoding Captchas - with B-ID there's no need to
verify the damn email each time you register.

------
tomjen3
Anything that means I won't have to use yet another password is a good thing.

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.

~~~
unicornporn
I had to create an account a couple of days ago because it was the only way to
log in to openphoto.me. Are there any clear differences between BrowserID and
OpenID?

~~~
thristian
OpenID requires the user to remember what sites they have accounts on that
provide OpenID authentication, and requires them to remember their
authentication information for those sites every time they want to log into an
OpenID-using site.

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.

~~~
sp332
I don' really need a foo@browserid.org address to register there right? So I
could actually get the same email address verified through multiple providers.
How would the browser know which one I actually want to use?

~~~
zobzu
you can use the email you like you select which of your registered email you
want to use at first sign in (sign in that doesnt require password)

------
cpeterso
What does BrowserID do that every existing OpenID provider cannot? The
BrowserID FAQ says the architecture is "decentralized", but login relies on
Mozilla's browserid.org server.

~~~
resnamen
It provides a canonical identifier for your account without compromising your
identity to BrowserID-enabled services. The OpenID spec divulges who you are.

~~~
icebraining
_The OpenID spec divulges who you are._

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.

~~~
laconian
The OpenID identifier can act as a relational key across services.

~~~
icebraining
So can the email address in BrowserID, or the username in the typical
user/pass combination. If you don't want to be connected, use different IDs
for different services. Nothing in OpenID prevents a person from having
multiple identifiers; in fact, Gmail generates different identifiers for each
domain you authenticate on: [http://blog.stackoverflow.com/2009/04/googles-
openids-are-un...](http://blog.stackoverflow.com/2009/04/googles-openids-are-
unique-per-domain/)

------
Ecio78
I'm working on a webapp that will be used by not-so-tech-savvy working people
and this could be an interesting way to subscribe to the service without
implementing generic openid (i think most of them wont understand it) or
facebook/twitter etc.. login (it's a service for businessman). I must check if
it's more difficult to implement than an all-internal email subscription and
verification process.

~~~
jmathai
BrowserID is super easy to implement. It's 8 lines of Javascript and about 8
lines of code on the backend to verify that a user owns an email address.

I've implemented it on OpenPhoto and absolutely love it.

~~~
StavrosK
Can you give me an invite code? I'd love to try BrowserID out and openphoto
looks interesting! My email is in my profile, if you need it.

~~~
jmathai
Sent.

~~~
StavrosK
Fantastic, thank you!

------
vlasta2
Maybe I do not understand the system well enough, but isn't there too much
room for fake accounts? The web site implementing BrowserID must trust the
browser or the 3rd party validation service that the user really owns the
specified email, right? Wouldn't it be super-easy for a hacker to simply
return bogus values from navigator.id.getVerifiedEmail() when that gets
implemented in browsers? (more specifically, what is the verification
procedure of the "Primary Identity Authorities" and what stops a hacker to
create a fake one?)

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.

~~~
thristian
As I understand it, the authentication token you get back from BrowserID is
signed by the entity that verified that the email address is real; at the
moment, only browserid.org is signing tokens, but presumably there'll be some
scheme where you say "I have a token for foo@example.com, so I'll request the
public key of example.com and validate the signature on this token".

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.

------
Newky
It would be interesting for this to get some exposure from a large web-
service. Being realistic, Facebook nor Google would be interested in replacing
their own system. But I think it is an interesting idea which now is no longer
just theory.

~~~
stephank
Well, Google wouldn't replace their login process because they _are_ the
BrowserID primary. If you have a gmail account, BrowserID expects you to be
logged in with it, which essentially means you're logged in to Google. (They
could add it for non-gmail Google accounts, I guess.)

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.

------
MatthewPhillips
>Include the BrowserID include.js library in your site by adding the following
script tag to your pages <head> tag <script
src="<https://browserid.org/include.js> type="text/javascript"></script>

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.

~~~
lloydhilaiel
Hi MatthewPhillips,

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

~~~
MatthewPhillips
Actually I went to the Documentation and clicked the link there, which
actually takes you to the github source. Completely my bad, having a license
header is not abnormal. I jumped the gun because the Open Web Apps shim wasn't
minified for quite a while.

------
riffraff
>>> Error encountered trying to complete registration. >>> Thank you for
signing up with BrowserID.

Quite a bit too experimental for me to register I'm afraid

------
alexchamberlain
Why has this been developed? I would have like to have seen a way for clients
to generated client-based SSL certificates and submitting them to a server for
signing automatically. This would be little new technology and proven
cryptographically.

~~~
gizzlon
Probably because client-based SSL certificates have been around forever, but
no-one uses them.

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.

~~~
alexchamberlain
They are brilliant, but they need to be more accessible. Hmmmmm... maybe I
should provide a patch for Chromium/Firefox.

~~~
zobzu
i wouldnt say brillant the CA model is still a pita where you've to pay for
certified authorities that are backed up by the vendors

and then, those certified authorities still fail to secure themselves

it certainly made a lot of sense but in reality its not _that_ good

~~~
icebraining
The CAs don't need to play any part in client-cert based authentication. You
just generate a cert locally and then copy the public key to the site when you
register. Subsequent logins are performed by the server checking if you own
the right private key that matches the public key used on registration.

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.

~~~
gizzlon
_"You just generate a cert locally and then copy the public key to the site
when you register."_

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

------
deno
Does BrowserID addresses in any way _authorization_? Is it compatible with
OAuth2?

------
extension
Hmm.. so if my browser has integrated support, then any site I visit can add
itself to my list of primarity authorities as evil-username@evil-domain. And I
will be asked to choose one of these authorities to log in to other sites. And
a rogue authority can impersonate me on the sites where I use it. Is this
correct?

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.

~~~
icebraining
I'm not sure if "any site I visit can add itself to my list of primarity
authorities as evil-username@evil-domain", but I do know that the login to the
authority is done using Public Key authentication, which unlike passwords
isn't subject to phishing. There's no risk in logging in to a rogue authority,
since the key never actually leaves your machine.

~~~
extension
I don't mean logging into an evil authority, I mean tricking the user into
using an evil authority to log in to a relying party. There evidently is or
will be a way for web sites to tell your browser that they can serve as a
primary authority for some particular email address at their domain. When you
visit the evil site, it would register some misleading email address, which
your browser would then show in the list of identities whenever you log in to
a relying party.

At best, we will still need some way of filtering out junk from the identity
list.

------
lisper
For an even simpler alternative to BrowserID see: <http://dswi.net/>

------
romaniv
I was hopeful about this protocol, but now I'm kind of disappointed. It uses
email and is built into the browser, so why does it require JavaScript on the
user side and a complicated verification server on the server side? I was a
hoping for something simpler.

