So, BrowserID is buzzing. In general, browser helping user to secure their login is a good thing. But, I have bunch of problem with the current state of BrowserID. I feel like it has gone back to the era of OpenID 1.0, which had numerous problems.
Privacy Advantage?
In How BrowserID differs from OpenID, it is stated that:
With BrowserID, by design, your identity providers are not involved in the login transaction. This means they need not be aware of your entire Web activity, a significant privacy advantage. With OpenID, your identity provider is, unfortunately, a necessary participant in the login flow.
Really? What about when the user is prompted to login to the BrowserID provider? Referrer is actually sent from the web site to the email provider or people like Browserid.org. See below.
https://browserid.org/sign_in GET /sign_in HTTP/1.1 Host: browserid.org User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ja,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7 Connection: keep-alive Referer: http://myfavoritebeer.org/
Not to mention, the same happens when myfavoritebeer.org verifies the signature at browserid.org.
So, BrowserID actually tells the BrowserID provider to which site you went, just like in the case of OpenID. In addition, Unlike OpenID, BrowserID has no option of using PPID (pair-wise pseudonymous Identifier), so it actually is increasing the privacy risk. Web sites can correlate your activities to learn something you did not want them to learn. [*1]
Password Anti-Pattern
Also, BrowserID.org actually is a typical example of password anti-pattern.
I actually got almost phished by BrowserID.org; I entered my Gmail Password to their dialogue.
It does not stop here. The mail address and password is sent in GET request!
https://browserid.org/wsapi/authenticate_user?email=******%40gmail.com&pass=********
So my Gmail password is actually stored in BrowseerID.org access_log.
Oh, what a bummer — I have to change password of Gmail now!
Private Key Compromise
Also, I think it is worthwhile to note that if BrowserID provider’s page has XSS, private key of the user may be extracted by the attacker. Of course, if the User’s PC was infested with mal-ware, private key is also compromised. In general, user’s PC is not a very safe place. Good percentage of user’s PC are actually infested by mal-ware. This is the reason why Denmark government has moved away from Software Certificate based authentication to server side HSM based authentication for their citizen.
Impersonation Problem
There is yet another problem. Identifier recycling problem. Suppose you were using your company email address with BrowserID. Now, you moved to another company, and your email address was reused. What happens? Your accounts at those web sites are going to be impersonated. This does not happen in OpenID, since user supplied identifier and the verified identifier are different. The later will never be reused.
It is actually quite simple to fix this problem with BrowserID. Just combine the unique non-reassigned string as the canonical user identifier in the certificate. I do not understand why they do not do this.
Conclusion
BrowserID as it stands now is insecure and increases privacy risk.
We need to wait till browser vendors built in the capability including secure storage for BrowserID to be safely used.
[*1] There is a detailed study about the privacy issues of BrowserID by Roger Clark at http://bit.ly/piPbb2
Hi Nat,
Thanks for writing this!
With respect to the fact that information is leaked back to the IP (browserid.org), this is only the case until we have native browser support. browserid.org is a requirement to bootstrap the system, and mozilla incurs the cost of running it and commits to running it with the transparency and level of responsibility you’d expect. Ideally though, we’ll see browserid become popular and will get all major browser vendors on board, this eliminates RP to IP (browserid) leakage, because the *browser* becomes the implementation provider.
As far as verification, the central verification service is provided as a convenience. By design it can and should be run by the RP. A community member has already written a verification library in PHP, and as we progress we’ll work to ensure that robust verification implementations are available for all important web development environments. By encouraging and making it easy for RPs to own verification, we plug this information leak.
The password anti-pattern you discuss is a real problem. In the next several weeks I hope to implement a UX iteration under Alex Faaborg’s guidance and this is one of the issues we hope to address. I’ll blog as I go and you can follow our progress on github.
As far as passwords over GET, that’s fixed 2 days ago and I’ll push it into production shortly: https://github.com/mozilla/browserid/commit/c53307230a13706bdc3ea7cbb6a930f8b3ea4f15
Private keys might be compromised by an attacker with access to your device, but so can today’s credentials stored in your browser profile and password manager. I don’t see increased risk.
Finally, right now there’s some excellent discussion going on on the identity mailing list, and one of the topics of discussion is how we can help the user deal with email addresses that are compromised or they loose control of. This is one problem of many that the community is working through in the open – while some solutions are proposed I don’t know that we’ve yet struck the perfect balance: a mechanism that is simple for RPs to implement while being discoverable and making sense to users. I’d encourage you to come discuss your proposal on the list: https://lists.mozilla.org/listinfo/dev-identity
Again, thanks for the excellent criticism!
lloyd