I.T. Security and Linux Administration

Jul 29 2011   7:25PM GMT

BrowserID Response

Eric Hansen Eric Hansen Profile: Eric Hansen

Yesterday, I wrote an article on Mozilla’s new BrowserID (aptly titled, “BrowserID“). When I woke up in the morning, someone on Twitter had responded to my Tweet announcing the post by basically saying that there isn’t two factor authentication involved (yet), and that most people do have JavaScript enabled. Click continue to find out why this strangely bothers me…

This is the Tweet in question. Now, I respect what @thunder said, and in some ways, he is correct. However, if you look at how the BrowserID system is developed, you will see something: it does in fact use two-factor authentication. This system is defined as something you know, and something you have. While most of the time this is your account log in information, and an authenticator app, this doesn’t have always be the case. You already have something you know (your log in credentials), and there’s also something you have (an e-mail service provider). My question is how is this not two-factor authentication?

Secondly, I’ve got no real proof in the amount of JavaScript off/on numbers, which is why I made an assumption in my statement. My assumption for this is based off of the popularity of NoScript (and to a lesser extent, AdBlock). When NoScript is installed, it disabled (almost) all JavaScript on the page, and you have to enable each script. Could this be circumvented in BrowserID code by embedding the log in information in an already-given JavaScript file? Sure, NoScript only blocks the resource, not the code/data itself. However, there’s also the other method of just disabling JavaScript completely in the browser settings. Do I see that being used a lot? No, not really. Why should it, really? You’ll end up just turning it back on again probably anyways when you find out sites like YouTube and Google’s services don’t work correctly, if at all.

Don’t get me wrong here. This post is not meant to flame @thunder, but this is meant to address the claims laid out to disprove my post. If I’m missing something here, then I’ll gladly be the first to apologize and take a stance towards BrowserID, but I just feel that this system is by its own design, meant to fail. The theory of the process and security it gives is wonderful. The problem here is asking the MTA (and/or MTU) developers to implement another protocol. Yes, there’s a work around, but its pretty much I.T. 101 that single points of failure will not lead to long-lasting systems. Even if some do, I don’t see others such as Google (Mozilla’s biggest competition) easily giving into their security feature. Instead, if Google even decides to tackle this one, I see them developing a different type of system. But, then again, BrowserID itself is nothing but a single point of failure anyways…i.e.: what happens if the service is down, and a site only accepts BrowserID authentication? Not the best design.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: