2FA in Password Managers: Fair or Faux

It all started with a tweet I sent regarding the position on passwords and password managers that a member of Microsoft Research was taking in an NPR article (I’ll expand on my viewpoint in a later blog post). But one of the resulting responses I received sent me down a very interesting rabbit hole.

Screen Shot 2015-02-27 at 4.39.32 AM

Faux 2FA? Of course I was intrigued. This led to an extensive and interesting twitter discussion with Paul Moore that I have captured here on Storify. I’m not going to recap the entire debate here. But in the course of the debate, Paul Madsen did link to a post Paul Moore wrote explaining his theory of why Password Managers that support 2FA are not really 2FA. In it, he isn’t actually questioning the 2nd Factor (like use of Google Authenticator or a Yubikey) but actually the 1st. It is a worthwhile read, but to evaluate it requires first understanding the mechanics of password managers.

Password-based Authentication Without the Password?

Most good cloud-based password managers require the user to set a Master Password, but do not store this in the users account or in their vault within the cloud service. It is used in the client (usually the browser add-on, or on the vault web page itself within the browser using Javascript) to encrypt an application password before sending it to the cloud service for storage in the vault. Retrieval will pull the encrypted application password down to the client, where it is decrypted locally.

Since the Master Password is never sent to the cloud service, the question therefore arises: How does the client authenticate the user when they want to retrieve a password? For the purpose of this exercise, let’s assume the user hasn’t enabled 2FA on their password manager (tsk, tsk). One of the password managers I like, LastPass, addresses this in this support article. Put simply:

At account creation time:

  • User is asked to specify a Username and Master Password
  • LastPass (unclear whether this is done client side or server side at registration time) generates an Encryption Key from these 2 elements. This simple algorithm makes it possible to regenerate that Encryption Key at any time given just those 2 elements (and is why your Master Password needs to be really strong and unique)
  • Most services that support username/password based 1FA store 2 things server-side: the username and a hash of the password (hopefully salted). LastPass also stores 2 things server-side: the username and a hash of a “generated password”. This “generated password” isn’t the actual Master Password of the user, but a password like value that is generated by recursively hashing the Encryption Key using the Master Password a large number of times using a strong algorithm. If this is all done server side at registration time, then the Master Password is promptly forgotten so it doesn’t exist anywhere server side.

Subsequently, during normal day-to-day usage:

  • When the user enters their Username and Master Password into the client, the client generates the “generated password”, and sends that along with the Username to the server. The server does a typical username/password generation to authenticate the user by hashing the incoming “generated password” and comparing it to the stored hashed “generated password”, and if it matches, authenticates the user and returns the encrypted vault to the client.

This looks like typical username/password 1 Factor Authentication, except that what is sent to the server for it to authenticate the user isn’t the actual password but a generated password, which is fine since the server has stored the hash of the generated password. And it is that distinction between the transmission of a generated password versus the actual password that is at the heart of Paul’s contention.

Much Ado About Something?

As he pointed out in the twitter debate, for this authentication flow to meet the definition of a 1FA flow per NIST 800-63, the transmitted password that the server uses to authenticate the user must be something the user knows. And his contention is that the user does not know the generated password being received by the verifier, so it doesn’t meet the requirement. Here are some reasons (in no particular order) why I contend it does.

1) The “generated password” can only be generated when the user is there to provide the Master Password to generate it. Arguments that someone other than the user can authenticate using the “generated password” without knowing the password is a red herring, because it assumes that someone other than the user can capture the “generated password” (by exploiting the plugin, or capturing the transmission) and replay it. But that is the exact same vulnerability the password itself is subject to. My assertion is that if you exclude all attack vectors that allow a 3rd party to capture a password itself, you are left with no attack vectors on the “generated password” either, giving them the same characteristics.

2) NIST 800-63 Appendix A Section A.3 (Other Types of Passwords) talks of “composite passwords” that combine randomly chosen elements with user chosen elements to ensure min-entropy. Clearly the user wouldn’t know this “composite password”, but my interpretation is that the document considers this acceptable as a password factor. By that logic, generated passwords that are based on the user chosen Master Password should be acceptable as a password factor too.

3) A users fingerprint is a commonly used example of a something you are factor in NIST 800-63 (even if it does not permit the use of biometrics as a token). However, in common biometric authentication flows, the actual fingerprint image isn’t transmitted and stored. Rather a biometric template that is derived from the fingerprint is. So a transform based on the raw data is considered to meet the requirement to be a factor. The “generated password” is no different in that way from a biometric template.

Wasn’t This About 2FA?

Indeed. And if you accept that the “generated password” model is a valid authentication model on its own, thereby constituting a 1FA, then adding in a something you have factor like Google Authenticator should therefore be elevating it to 2FA. If you don’t accept this contention, then I guess it’s faux.

There is one wrinkle though. Paul pointed out that for an authentication model to be 2FA, both factors cannot belong to the same something you * classification. And one could read NIST 800-63 Section 6.1.2 to claim that because the browser add-on is needed to create the “generated password” for transmission, the authentication flow technically becomes a something you have flow, with the Password Manager being a Single-factor (SF) Cryptographic Device. However, I don’t think that flies since a user can use a completely different browser or device that they have never encountered before, provide the Username and Master Password, and authenticate successfully.

Interestingly enough, I’ve recently been introduced to the Unbreachable Passwords capability of CA Advanced Authentication. I wonder how the arguments here would bear on that, since the authentication server doesn’t receive the user’s memorized password there either.

So what do you think? Do I have a case? I would love to hear from folks (in the comments or on twitter) who have been heavily involved in the standards and authentication space, especially if you’ve made the effort to participate or dig into the NIST standard.

CandH-KnowledgeIsParalyzing

[Update 03/03/2015]: I’ve captured the follow up discussion on Twitter on Storify here.

10 Comments