From the ‘Your Email is Yo
ur Password‘ files:
Since the beginning of the Internet era, your email address and your ability to verify that it’s actually yours has been the lynchpin of Internet identity.
You want to join a new site/service? Sure! Just verify your email address…
Mozilla is now making that whole exercise easier with a new effort called BrowserID. Basically what it does is it keeps your verified email in the browser and then compliant BrowserID sites can verify that address when you click on a button.
“BrowserID implements the Verified Email Protocol, which is designed with security in mind. Sites get proof of ownership using public key cryptography—but don’t worry, we have a verification service so you can get started without writing a single line of crypto code,” Mozilla’s demo site for BrowserID states.
Since the ID is technically stores on the local machine, Mozilla is not actually storing anything on their servers, so there is also potentially less risk for information leakage.
The actual code needed to implement BrowserID is trivially simple in my opinion, which could make this system very easy to implement.
Could this be an oAUTH killer?
Likely not…oAUTH is already widely deployed and has demonstrated itself to be massively scalable and highly federated. BrowserID is still an early dev project, but it holds a whole lot of promise. BrowserID isn’t really creating a new ID store, as is the case with oAUTH, BrowserID is just providing us with a new way to use an ID we already have — our email addresses.
Just as oAUTH has potential security risks, there are some considerations for BrowserID too. Jeremiah Grossman, founder of Whitehat Security (and all around good guy) tweeted that :
“One threat model would be forcing somehow forcing un-authed users to login (BrowserID), deanonymizing them, and grabbing their email addy.”
Another would be XSSing the BrowserID domain, steal the auth-cookies, & then attacker may login (as the user) to anything support it. @jeremiahg
As with all web app security issues, users need to be vigilant about the sites they visit and what they actually click. When it comes to XSS, CSRF and Clickjacking, the same protections/mitigations that site owners are already taking (and the same risks) are still in play.
