Browsing through various articles, there was one on Linux.com that caught my eye. It talked about Mozilla’s new “security feature” that is meant to, what seems like, take over the (rather limited) market that OpenID has created. Granted, it doesn’t directly take aim at it, but is the best way to describe its purpose in the world. Not to mention, they are calling it BrowserID. If you’re wondering what makes this any different, please continue.
These days, a lot of people are relying on external sources to keep their passwords safe. Such products as KeepPass and OpenID, even using document processors like Writer/Word are being used to keep track of users’ passwords for various sites. This system, however, relies only on your e-mail, and a certificate server. Now, Mozilla seems to be thinking in the long term here, as the official idea is that your e-mail provider will also act as the certificate server, but as not many people are really jumping the gun at this new technology (surprise!), Mozilla is offering what can be compared to as a CA root server at browserid.org.
As according to the article on Linux.com:
The login process for a BrowserID-compatible site starts with the site asking for an email address and proof-of-ownership (which is called an “assertion” in official BrowserID parlance). In the simple method, in order to log in, the user’s browser and email provider will both need to support the assertion-generation process, but there are provisions for working around this. In any event, however it is generated, the browser returns an assertion that includes the email address in question, an “expiration date” (so that ne’er-do-wells can’t capture and replay logins later), and an address-ownership certificate.
The assertion is in JSON format, but it is also cryptographically signed with a private key that never leaves the browser machine. The site can verify the validity of the assertion because the ownership certificate includes the public key associated with the private key that signed.
Basically, this is a key exchange of data. I do like how they put an expiration date on the data, but can only see this causing more headaches than its worth. But, really, here’s the deal from where I see it.
I think the better what to do this is make an authentication service. While this is that, it seems more like a two-factor authentication measure than anything else. You need your e-mail, and you need your site information. The problem is, basic two-factor authentication is easy to implement and maintain, while changing standards and protocols are not. Personally, I like how Google has their two-factor set up. You have your site log in, and you have an authenticator program for your phone you use for the second part. My biggest complaint with this, is what if you’re viewing a site off line? Is it going to still ask you for information? Or even what if you’re using the browser for Intranet use only…not every company allows every Bill and Jill to browse the web freely.
Do I think two-factor authentication is a great way to calm down account theft? Definitely…I had it set up in GMail for a long time, use it in other systems as well. Do I think the way BrowserID works is the way to go about it? Not so much.