FIDO U2F for 1P subscription accounts?

@BXIA: You raise some good points. You're right that we as users will always be the weakest link in our own security, especially since so much of it depends on choices we make. 1Password is here to make it easier for each of us to make better choices, but "security" is a process, and not something to be used as a cudgel against the user. So while we should (and can) help people make better choices, we shouldn't (and can't) make the user do what's best for them; we can only provide the tools.

So you might be thinking now that, given these considerations, multifactor authentication is a perfect fit. But it's important to keep in mind that 1Password's security is based on something bulletproof: encryption. Authentication can be useful too, and it would certainly check that box on the table there, but 1Password isn't here to check boxes. There are a lot of other features we could add too, but it's important to factor in both security benefits and usability.

In the case of TOTP authentication, it doesn't improve encryption, which is the only way our data is truly secure. The authentication adds an additional step to accessing an account, but adding a step doesn't necessarily improve security. It's just another hoop to jump through. Of course, under ideal conditions, authentication means there's a certain burden of proof required to access sensitive information. But if AgileBits, as the gatekeeper, is compromised, someone else is in that position instead; or similarly, the TOTP token could be intercepted, either by compromising the device or the network being traversed. At that point the multifactor authentication provides no additional security and is essentially a placebo. And that's not something that helps anyone. That brings us right back where we started.

And of course then we're talking about the Account Key again. I think it's important to note that while you could store this on an insecure public webpage, the fact that this is possible doesn't make the Account Key insecure any more than we should get rid of credit cards because they can be misused or misplaced; anything can be. In the case of the Account Key, however, it has a few big things going for it:

1. The Account Key is generated on a single device (at account setup) and never transmitted.
2. The Account Key is random, so it's actually making our weak (relatively speaking) Master Passwords (which we need to be able to memorize and type) stronger.
3. The Account Key is used (along with the Master Password) to encrypt the data.

So someone absolutely needs access to both the Master Password and Account Key to be able to decrypt your data, even if they gain access to our servers. So unless you give these away, someone else having them (and, therefore, accessing your data) is an impossibility. Your passwords aren't stored "online" the way you implied; everything is encrypted locally on your device, so the server only ever gets an encrypted blob.

Now, when it comes to usability, multifactor options are often cumbersome, easy to lose control of, or just plain easy to lose (physically). If you love your LED dongle and have never lost it, you may be in the minority. On the other hand, we've been testing Duo multifactor authentication with 1Password Teams, and so far it looks promising. Since it can be tied to a device and uses a separate secure channel (e.g. not placing us in the "gatekeeper" role), it provides some benefits that many other options don't. But from my experience so far, I think chief among these is the ease of use. That's where a lot of other solutions I've used have really been lacking. I'm not sure that it's feasible to bring this to all 1Password Accounts, but this is certainly something we'll consider (along with other options) as we continue to improve 1Password.com. Thanks for letting us know that this is something you're thinking about as well! :)

I'm not sure that is written in stone. Little is. Certainly our priority is to bring it to 1Password Teams, but then we'll see from there.

Ben

Well, authorization is still important, especially we can't verify that every environment is trustworthy when you are using others' computer via 1Password.com etc.

@BXIA: It sounds like you mean authentication. While it is certainly useful, a bug in an authentication system could grant unauthorized access, which is a weakness which encryption doesn't have. Encryption uses math to enforce security, not permissions, which is why that's the foundation of 1Password.

Account keys can be easily key logged, and it is STATIC, everyone can access to my database once thay key logged the keys.

I think "easily" may be a significant overstatement. Given that the Account Key is generated locally, never transmitted, and only used initially to authorize a new device/browser, the opportunities for it to be "logged" even on a compromised machine are fairly limited. Certainly there are always risks, but someone who is in a position to capture your Account Key (or Master Password) already, by necessity, owns the machine, and they can almost certainly get what they want other ways at that point.

A dynamic changing 2FA option will be much better, it's the best way to deal with distrust environment.

A dynamic code can be intercepted on a compromised channel the same way you're pointing out that the Account Key could, so it certainly isn't "better". But using both in concert can be useful, provided we don't make it more difficult for someone to legitimately access their own data. Definitely something we'll continue to evaluate.

If I'm right account key on Windows is stored as plain text, so pretty easy to get leaked.

@BXIA: Not that I can see, but if you're able to find the Account Key stored in plaintext on your system that's definitely something we'll need to look into. Please shoot us an email at support+windows@agilebits.com with the details!

I think combine authentication with encryption will a good idea, it definitely worth to try.

The only potential downside is usability, so if we can find a way to make it accessible it will be pure win. That's really our mandate: 1Password is for everyone, not just self-avowed nerds like me.

As a long-term user of 1Password, I agree with the sentiments of the article. I worry about keyloggers, and there are many possible man-in-the-middle observer of 1Password passwords. Bluetooth keyboard, USB logging, other mechanisms.
I would prefer to be in control of my options, rather than having them dictated by the opinions of my password vault provider.

@greening: The only way to truly have any meaningful control over your options in that scenario is through control of your machine and the network you're using. If someone else is in control, you're really at their mercy...unless you simply leave 1Password locked and your data encrypted. Then you're good, but that's considerably less useful.

We go to a lot of trouble on both ends — both in the app, the browser, and on the server side — to reject insecure, untrusted, or otherwise questionable connections. But with or without a dongle, if you're sending information from a compromised machine and/or network, you have the same problem. They may not be able to independently access your data in the future from another machine (in the case of a one-time password), but that's small consolation if they were able to get all of your data in the current session.

Giving the user more options is always something we consider, but very carefully. You make it sound like it's just flipping a switch: "Ta-da! More options!" But I think it's important that anything like that be carefully vetted, developed, tested, and supported on an ongoing basis, in addition to being accessible. And ignoring the question of accessibility — so that anyone can use it — feels a lot like, "Only those with the same requirements and technical savvy as me matter". That's not the way we want 1Password to be at all. Any of us can say "I want U2F/YubiKey/etc." but what any of us wants individually is not the only consideration.

@jordan_b1: I think it's important to keep in mind that the Master Password and Account key are never transmitted. That changes the landscape significantly. For example, as far as I know, Google does not use SRP. So a person-in-the-middle attack may be used to intercept login credentials — including the TOTP. Whereas even if a person-in-the-middle were possible with a connection to 1Password.com (currently this does not seem to be possible, given the strict security measures in place), they still cannot capture your login credentials because you never send them.

That said, you make some excellent points: about the static nature of passwords in the context of a compromised machine, where they could perhaps be captured when entered; and revocation. While it's a bit different (1Password doesn't use cookies for authorization and revocation) because revocation for any authorized app or browser is already possible within the web interface, revoking all of them is not intuitive. They can be revoked one by one, by performing recovery on an account (by 1Password Families/Teams Organizers/Owners), and also by using the Regenerate Account Key option in your profile. This is certainly something that could use improvement. Thanks for your feedback on all of this!

Right now it doesn't apply to 1Password for Windows. We're working on adding that to the app.

It's certainly something we'll consider. :)

@niallyoung: Very interesting. It may be possible, and we'll continue to explore different options. However, I think it's important to keep in mind that we really have to design 1Password so that is secure for everyone who uses it, not just folks who can afford dongles and manage GPG keys. We're responsible for ensuring that 1Password users' data is secure right up until the point where the database and Master Password (and Account Key) are in the possession of the attacker. And it's important to note that 2FA doesn't protect against this final scenario either, since it's being used for authentication. having the database and the keys needed to decrypt it bypasses authentication. I agree that 2FA can provide benefits in situations leading up to that, but can also be a significant point of weakness, as in most cases the user needs an escape hatch in case they lose the secret or can't connect, in the form of resets or offline codes. There's a more "hardline" approach that can be adopted of course, but along with the security benefits, the risk that the user will get locked out of their own data is much higher. The ultimate security of course is destroying the key, but at that point security isn't benefitting anyone. So there's a lot more that has to be taken into account.

Hi @attrapereves - We appreciate the feedback and thank you for sharing your use case with us. If you're using a public computer (at a friend's house) and want to log into your 1Password account, you could manually type in the Secret Key from your trusted device. For instance, if I'm at my Dad's house and I need to log into my Families account. I go to the sign in page then I open 1Password on my iPhone then manually type in the Secret Key from there -

https://support.1password.com/account-key/#if-you-added-your-account-to-the-1password-app

I hope this helps and again thank you for letting us know about a feature you would like to see implemented in the future. Have a great day!

Hi @niallyoung - We appreciate the additional clarification, and I'm sure @brenty will be happy to reply back soon. I completely understand your suggestions and you're correct not everyone has Touch ID. As Brenty stated previously, "we'll continue to explore different options." It's definitely a touch balancing act between security and convenience. Thank you again for reaching out to us and sharing your thoughts. We're always happy to listen and the door is always open :-)