Posted by: Eric Hansen
when relevant content is
added and updated.
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?
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.