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.
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.
[Update 03/03/2015]: I’ve captured the follow up discussion on Twitter on Storify here.
About The Author
In any authN system worth its salt (pun intended) the user has no knowledge of what is transmitted on the wire. The system you describe is not qualitatively different. As it states in the Exec Summary of the NIST doc: “the individual to be authenticated proves that he or she knows or possesses some secret information” which the user needs to do to generate the password.
QED
Short and succinct. Thanks Dave.
The issue is not if the user knows what data is sent over the transport layer… it’s that the actual secret is never presented to the verifier for verification.
If I give you a password, you (as the verifier) know that I (as the bearer) categorically “know” the password. There can be no denying that fact.
If I give you a hash or a derived cryptographic key, you can assert (with a high level of certainty, but assert nonetheless) that I probably know the password… but that assertion is no longer as strong as a statement of fact. Weaknesses (known or unknown) in PBKDF2 and/or the cryptographic algorithm used to form the hash could alter the output, such that you can no longer trust, with absolute certainty, the bearer actually “knows” anything. If we’re saying it’s “as safe” because it uses PBKDF2/SHA256^5000, where do we draw the line? If the password is hashed at the client-side using MD5 (with plenty of known collisions), can we state with the same assurance that the bearer of the hash actually knows the password?
I’d argue, no… but because that’s the case regardless of the algorithm, you can’t and shouldn’t claim to be presenting a secret to the verifier when you’re actually presenting a deterministic result of something which *could* be vulnerable.
To say that the actual secret is never presented to the verifier defines that the secret is the password, not the password hash. Since both parties have to involved in defining and agreeing on the secret (as defined by NIST), that would be the password hash, not the password. And point number 2 I made specifically addresses that.
And you’re right that it is about drawing a line. There was a time when MD5 was good enough, and over time, as tech and scale changed, the line moved up. Such is the way in tech life. Biometrics were once considered infallible, now not so much. And whatever we define today as Level 4 might be Level 1 in a decade.
Your assertion (!) is fixated on whether the bearer of the hash actually knows the password. The fact that most passwords can be guessed would render that below the line in my opinion, since receiving a password from a user doesn’t mean it was the same user that set it up.
Neither is the biometric (something you are) nor the hardware token (something you have) itself presented to the verifier, but a hash of some arbitrary number. That hash is not my fingerprint, nor my SecureID – nor my password. Nevertheless, it is the thing presented and so satisfies the criterium for one factor of a multi-factor authN system.
You’re absolutely right. The secret used with the verifier is the hash. My point is, it’s not a “known” secret. We can assume they know it, based on the result of the hashing process, but we can’t be absolutely sure as every algorithm has weaknesses.
You’ve misunderstood the composite password topic though. They’re outlining ways to ensure a minimum level of entropy by choosing elements of their password for them, with the remainder being something they’ve chosen. It still results in something the user knows, or authentication would fail.
For example, if I force passwords to start
~~0 +
… we’re using a composite password & increasing entropy, but the user still needs to know it. If we choose to represent ~~0 as an image, the verifier still receives ~~0 +
We’re not debating authenticity here, that’s a different topic. We’re interested in proving the bearer knows the password, not that the bearer is the user.
I have a slightly different reason why the hashing of the password doesn’t change it from being a “something you know” factor. SP 800-63-2 defines a “token authenticator” as the output of a token (see section 4.3 paragraph 3) and that’s what the “generated password” is. There is always a token authenticator; it’s just that often the secret itself is used as the token authenticator. Performing some function on the password to derive the token authenticator doesn’t affect the type of token being used.
LastPass’s implementation strengthens the exchange because what’s transmitted on the wire (where it could be MITMed) isn’t the actual secret, and they have taken steps to make the token authenticator hard to attack offline.
Well, I’d say that what’s transmitted on the wire is the actual secret (since that’s what the server treats it as), and the Master Password is a secret generator…
Not quite, but I understand why it appears that way.
Technically, the master password is actually the token secret. The cryptographic key derived from it is the token authenticator.
Inherence factors aren’t classed as secrets as per NIST 800-63-2 and shouldn’t be presented to the verifier, not even if they’re hashed. They are recognized for use purely to activate another token; resulting in 2FA when combined with a knowledge/possession factor.
The possession factor is typically an OTP generator or cryptographic device; providing a token authenticator of either an OTP derived from a pre-shared seed or, given some arbitrary input, a token which may or may not contain a secret. It’s the pre-shared seed/asymmetric key used to form the token authenticator which proves possession of the device, not the device itself.
In any case, neither of those two scenarios apply to knowledge factors. Your only options are to provide a memorized secret, verbatim, to the verifier… or put it through some cryptographic process dependent on a pre-shared seed/key. That’s not the case here. Client-side hashing isn’t within the scope of NIST 800-63-2 at the moment, so until it’s revised, surely we must abide by current standards and treat them as token authenticators of an undefined type?
Ultimately, they are not memorized tokens and as such, aren’t something the user “knows”.