Two-factor authentication?

ashworth102680

No rush, but curious if there's a roadmap for this. I use a Yubikey as well as Google Authenticator for various things, and it might be handy to allow an option to require a new Google # from the mobile app after a certain amount of time, etc. Good to be paranoid :)

khad

Our existing blog post is useful for understanding the current state of multifactor authentication in 1Password, but it doesn't really address another very important aspect.

I'd like to highlight the distinction between an authentication password and a decryption password.

Let me give a simple example. Suppose you have a file encryption program called FileEncryptionProgram.app. It encrypts a file for you and stores the encrypted file as my-secret-diary.asc.

Now the developers of FileEncryptionProgram could implement a form of multifactor authentication before the application would even begin to think about decrypting my-secret-diary.asc. That wouldn't be hard to do on the Mac.

But now imagine what happens if Mallory (an attacker) gets ahold of my-secret-diary.asc. Mallory can take that file off to his secret lair and try to attack the encryption on it. Mallory does not need to launch FileEncryptionProgram at all. Indeed, Mallory would be wise to use his own password guessing program that is built for speed and designed for the format of my-secret-diary.asc.

Mallory is trying the decrypt the data. Mallory does not need to authenticate with some particular program or service. This is the case with 1Password data as well. Anyone can write a program that decrypts the data if they can get the master password. The data is protected by the encryption and the design of our data format. An attacker doesn't need to (and typically wouldn't) go through the 1Password application itself. In fact, this is exactly what John the Ripper does, and 1Password protects your data in ways which are appropriate to its design (i.e. PBKDF2 key strengthening).

Classical approaches to MFA won't work for us because unlocking your 1Password data is not about authenticating to some service. So sure we could add an authenticator for using 1Password.app itself, but it wouldn't actually provide any real additional security. It would be just for show.

Instead we would need a key splitting approach, and it would need to work across platforms. We do have ideas of how we could do this, but it would add complexity everywhere, and to every platform. It couldn't just be an option that you use on one platform but not another. (If it were, it would mean that the data could be decrypted without the second factor.)

Again, I'm not saying that we can't do it. (We have some good ideas about how we could.) But I am saying that at the moment we are disinclined to do it for the reasons outlined above and in our blog post. Even if it is made an option, we know that there are people who will sign up to every "more secure" option available to them, even if it is the wrong choice. We've joked about presenting people with a quiz about data security before allowing them to enable such an option, and still with a flashing red sign saying "This is a bad idea. Don't enable this."

Using a second factor in the way that we would have to doesn't just double the chance of getting locked out of your data, it increases those chances dramatically. This is because your 1Password data is backed up in a variety of different ways, with robust checks that it isn't damaged. But your second factor couldn't be backed up and stored with your 1Password data. And indeed, it would typically be stored on some other device (an encrypted USB drive or smartcard). Damage to that would be unrecoverable.

Anyway, thanks for bringing this up. We should do a blog post on the distinction between authentication and encryption passwords sometime. (The distinction is relevant to more than just MFA, it is also why you should only change your Master Password if it is weak. A good Master Password should be for life.)

BoydWaters

I get the idea: two-factor doesn't protect data-at-rest.

However, I am far more concerned with XSS exploits while using the various web browser 1Password extensions.

It would be very easy to present a web form that looks like a valid 1Password unlock screen. A user would dutifully enter the password into the exploit's web form.

If 1Password supported two-factor auth such as a time-based token, then Mallory-in-the-middle would have a limited amount of time to use the stolen password.

I can't trust my web browser. I'd feel more secure if I didn't have to fully trust the 1Password browser extension.

khad

Multistep authentication has clear and obvious security benefits. So it is more than natural for people to ask why 1Password doesn’t employ it. We're planning to write a more detailed explanation of our developing thoughts on it, but let's discuss the difference between authentication and decryption.

When you connect to some service, like Dropbox, you or your system has to prove that it really has the rights to log in as you. That process is called “authentication”. It is the process of proving to the Dropbox servers in this case that you are really you. You can do this through a username and password; you can do this through a username, password, and code sent to your phone; you can do this by having a particular “token” stored on your computer. Authentication always involves (at least) two parties talking to each other. One party (the client) is under your control; the other (the server) is under someone else’s control.

1Password, however, involves the 1Password application (under your control) talking to your 1Password data (under your control) on your local disk (again, under your control). This is not an authentication process. So 1Password doesn’t even do one-step authentication. It does no authentication at all. 1Password doesn’t gain its security through an authentication process. Instead the security is through encryption. Your data on your disk is encrypted. To decrypt it you need your 1Password master password.

There are great advantages to this design: Your data and your decryption of it doesn’t require our participation in any way once you have 1Password. Your data is yours. Even if AgileBits were to get abducted by aliens tomorrow, you would still have access to your data since we never store it on our servers.

However, one disadvantage of this design is that the kinds of techniques used for multi-step authentication are entirely inapplicable to 1Password. Those techniques are designed to add requirements to an authentication process, but unlocking your 1Password data is not an authentication process at all. Because there is no 1Password "server", there are no (additional) steps we can insist on as part of a (non-existent) login process.

1Password is decrypting data stored locally on your system, it is not authenticating against some service. So in truth, we don't even have 1 factor authentication, as there is no authentication in the first place. So typical approaches to MFA won’t work.

However that doesn't mean that it is impossible for us to do something that looks like MFA. There are roughly two approaches (each simpler than PKI). One of them is key splitting. That is the result of processing your Master Password doesn't actually get you a working key to decrypt further, instead that result would need to be XORed with another 128-bit key. So it is simply a case of storing that other "half" of the key on some other device. 1Password would need to be able to read that device, which may be tricky on iOS, but it isn't insoluble.

The other approach would be to move the keyfile. 1Password (on the desktop) has a file called encryptionKey.js. That file contains an encrypted key, which is what gets decrypted by the key derived from your master password. That file (and some backups of it) are part of your 1Password.agilekeychian (which is actually a folder bundle, which looks like a single file on the Mac). It would be possible for us to allow that file (and its backups) to reside on some device or location. Both that file and the Master Password are required to get any further.

We are more inclined to do key splitting rather than having a movable keyfile.

The real technical difficulty is getting this to work on every platform. Again, because this is all about data decryption and not authentication, we can't just implement this on one platform (if it were to be anything other than just for show). So while this isn't insurmountable it means that even the "simple" approaches that I described would be tricky.

But the real reasons that we haven't put in substantial effort in that direction is because for every case where someone reports that their computer or device has been stolen, we get probably a hundred more of "I forgot my Master Password" or "I damaged my data and didn't have usable backups". My fear is that key splitting or keyfile moving wouldn't just double the rate of people getting locked out, but would increase it much more. The threat of data lose becomes very substantial.

Again, because we aren't running a system that people authenticate against, there is nothing we can do the help people recover their data if they damage a key or forget their Master Passwords.

Now of course we could make it an advanced option with lots of warnings, but we know that people will always dial up security settings to 11 whether it is in their interest or not. Remember that 1Password is a mass market product. It's great that security geeks use and respect it, but we don't want to give our users rope to hang themselves with.

I'm just spelling out why, to date, we have resisted calls for MFA. It's harder to get right for a decryption system than for an authentication system, and we think that it might do more harm than good.

None of this is written in stone. The threat landscape, patterns of usage, and device capabilities change. So while there are no immediate plans add this, we are leaving the door open in the design of our new data format.