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