Mozilla's BrowserID (single sign-on for the web) is live

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.

Can you explain briefly what the good reason is for no browser to integrate OpenID?

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.

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.

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.