Reanalyze 1Password (again)

1Password is incredibly responsive on Twitter and I've been watching their responses and Sam tweeted me this conversation as well: https://twitter.com/SamuelDebruyn/status/478550817432039424

Basically 1Password still believes they dont' belong on the list. They have a paper explaining it: http://cl.ly/text/302c041B1M0c

What does everyone think? I know @mxxcon was the one that argued that it should be re-added.

@jdavis the way I see that paper is they decided not to implement tfa/mfa because it's too difficult for users, not because they are immune to the problems tfa/mfa solves. Paragraphs 7 and 8 in their own article says that they could implement mfa using various approaches but decided not to. That twitter conversation is once again focusing too much on tfa for a service point of view. It is a common use-case but not an exclusive one. tfa can be implemented in stand-alone desktop applications as well.

I agree with 1Password on this. The services you sync through are the ones that use 2FA. 1Password doesn't use their own servers to sync anything. Nothing is seen by them and nothing is authenticated by them. The sync services look at the files where you sync them from for changes and other things.

On Mon, Jun 16, 2014 at 2:53 PM, Josh Davis notifications@github.com wrote:

1Password is incredibly responsive on Twitter and I've been watching their responses and Sam tweeted me this conversation as well: https://twitter.com/SamuelDebruyn/status/478550817432039424

Basically 1Password still believes they dont' belong on the list. They have a paper explaining it: http://cl.ly/text/302c041B1M0c

What does everyone think? I know @mxxcon https://github.com/mxxcon was the one that argued that it should be re-added.

— Reply to this email directly or view it on GitHub https://github.com/jdavis/twofactorauth/issues/585.

@jonathanbloom Two/Multi-factor authentication can exist not only in online services world. Previous example that I used is KeePass. See http://keepass.info/help/base/keys.html#keyfiles

One master password decrypts the complete database.
Alternatively you can use key files. Key files provide better security than master passwords in most cases. You only have to carry the key file with you, for example on a floppy disk, USB stick, or you can burn it onto a CD. Of course, you shouldn't lose this disk then.
For even more security you can combine the above two methods: the database then requires the key file and the password in order to be unlocked. Even if you lose your key file, the database would remain secure.

Without a password(something you know) and a key file on some sort of removable storage(something you have) you can't access the database. 1Password can implement such feature as well.

@jdavis If it's a really contentious issue, perhaps could we compromise on showing they don't have any tfa, but also an exception saying that they made a business decision not to implement it and link to that article.

I work for AgileBits, the makers of 1Password.

Two factor authentication may be a very fine hammer, but 1Password is not a nail.

I haven't followed all of the discussion here, but I would like to note that we do not consider key splitting to be the same thing as 2FA. Though perhaps you are defining it as such. At any rate, because 1Password is purely encryption and does not involve any authentication, I will repeat that 2FA isn't a coherent concept, as we aren't even doing "1 factor authentication."

The discussion that I see here does cover the two reasons that we have not (at his point) implemented key splitting, but I would like to clarify on them.

@mxxcon said

they decided not to implement tfa/mfa because it's too difficult for users, not because they are immune to the problems tfa/mfa solves.

It's really a combination of both (along with the fact that 2FA isn't even a coherent concept for an encryption based system). We face some but not all of the threats that authentication based systems face, and best alternative, key splitting, puts a huge burden on users leading to a substantial risk of data loss. I elaborate on these at what has turned out to be far to great a length below. (Yes, I really need to consolidate all of these various attempts to discuss these issues into a single paper.)

An encryption password faces different threats than an authentication password

If you look at the services where 2FA is most needed, they are to compensate for poor handling of passwords. These are for cases situations where people may be reusing passwords, passwords travel over untrustworthy networks (particularly if you wary of trusting SSL), or weak passwords in general.

One Time Passwords in a second factor, such as SMS (yuck) or TOTP (yay!) are terrific when concerned about a password stolen in transit. But again, this common way of thinking about password threats and options is neither needed nor relevant for encryption passwords used only locally. Note also that key splitting couldn't actually involve One Time Passwords, so key splitting is useless in an attack situation in which the attacker is able to get both the Master Password and the split key.

Quite simply, when threats are looked at carefully, the security gain of adding key splitting to 1Password is not nearly as substantial as what is gained by using a well designed second factor for an authentication system.

The risk to data availability

It is heartbreaking to deal with customers who have forgotten their Master Passwords.

No reset mechanism

The stakes much higher for loss of a split key than for the loss of a second factor. If I lose my Google Authenticator data, I will have a tough time, but I will eventually be able to get back in. If I were to lose a split key for an encryption system, then no force on Earth would be able to let me regain useful access to my data.

This, of course, is because of a another difference between encryption and authentication (and so you see why I insist on not using the term "2FA" for something like 1Password.)

When a 1Password user forgets their Master Password there is absolutely nothing we or anyone can do for them. They can prove to us that they are the legitimate owners of the data, but there is simply nothing we can do. (We occasionally encounter customers who don't believe us when we explain this.)

In a typical authentication system, however, you can go through a password reset process (which tend to be only as secure as email). Thus, a loss of one of the factors is not catastrophic. Password resets in such systems aren't pleasant, but they typically remain a possibility.

We can't back up split keys

1Password on the desktop is somewhat obsessive about making backups of its encrypted data, exactly because data loss can be catastrophic. But if key splitting were to be meaningful, we would never back those split keys, as doing so would defeat the security purpose of key splitting.

Key splitting will be on all platforms or none

Because the data can't be decrypted without a copy of the split key, users will not have the option of saying "use key splitting on my desktop, but not on my iPhone". That simply won't be an option. And we cannot synchronize the split key over the same channel that the data travels over. (Well, we could, but that too would defeat the security purpose of it.)

No security theater

We could, if we wanted to, offer an authentication step to unlocking 1Password. But this would be authenticating to our application only. This might make a nice show, and there are some very very limited cases where it is useful. (The PIN code we use for 1Password on iOS is a case where it is genuinely useful.) But in the general case, it might look cool and give an impression of added security, but it would offer no substantive defense against the serious attacker.

Those who need it most are the most likely to be harmed by it

There is, of course, a legitimate case for where key splitting would be useful. Users who use poor Master Passwords and have their data captured from something (say a sync service) can have their Master Passwords cracked no matter how much we ramp up PBKDF2 or other slow key derivation mechanisms. Key splitting would make such attacks impossible.

But remember that because key splitting will place a substantial burden on the user dramatically increases the risk of data loss, it is exactly those people who have poor Master Passwords (and so would have the most to gain from key splitting) who would be most likely to irrevocably lock themselves out of their data.

Looking for solutions

We do worry about customers who may pick poor Master Passwords, and we do want to serve customers who may fear the password cracking resources of a TLA. I'm not just trying to make excuses for why we don't do key splitting. At a minimum, I hope it is clear that key splitting is something that we have thought seriously about. There are some real threats that key splitting would solve, but ...

In summary

Two Factor Authentication is not applicable to 1Password
1Password Master Passwords do not face the same kinds of threats that most authentication passwords face.
Key splitting will not make as big a security difference for 1Password as 2FA does for most authentication systems.
If we are to implement key splitting, it needs to be done so that it does more good than harm.

I really do think that you should be treating authentication and encryption systems differently. We don't belong on your list. Encryption and authentication do have some common threats, and the difference is rarely apparent to users, but the subtle difference do matter greatly when considering what sorts of threats are present and what sorts of defenses are appropriate.

[Comment edited a couple of times to fix up some wording, get attributions correct and clarify structure.]

I'm sorry if this is rambly and sometimes doesn't make sense. I've been trying to post a reply the whole day..with constant interruptions.

@jpgoldberg there are 2 separate issues: Whether authentication = decryption. 1Password's decision to implement 2fa.

Lets address the 1st one.

You are making one critical mistake. You consider authentication and (en/de)cryption to be different processes. However, in a best-case "service" with strong user privacy regards they are one and the same. You will not be “authenticated” into the system until your (username+) password can “decrypt” your user profile. Yes, it’s not universal and some use-cases don’t allow/need that, but that doesn’t mean they are always 2 separate processes.

Even take your “offline software” as an example. It is irrelevant if I can authenticate myself to AgileBits Company. That makes no influence on the functionality of the application. What is relevant is if I can make sure that only I can access MY data in 1Password application. Only I supposed to have access to that data and so by the fact that I supplied my password (“something I know”) which decrypts my database file I “authenticate” to the application that I’m “authorized” to access that database. Additional authentication factors can be something I poses (split key, private key, etc.) and/or something I inherit/physically am (fingerprint, iris scan, colonic map :smirk:) Encryption is just an extremely reliable way of authenticating somebody.

Look at it this way: Let’s say you have your secrets somewhere on a paper out in the open. Obviously you can’t ensure secrecy of that data. Your next step is to put it in an envelope to hide it from unauthorized people. However, you still can’t guarantee that only you can access that secret data. Next step would be to make it unreadable to others even if they somehow manage to open your envelope. You scramble your data (ROT13). However, obviously it is still insecure. Your next logical step would be to protect your data using even more reliable methods such as cryptography. Hence you would use 1Password or any other type of encryption tool. All these methods still revolve around desire to ensure that only accepted people access that data.

Essentially what I'm trying to say is that decryption password is a more reliable way to authenticate yourself to a given system.

1Password's decision to (not) implement 2fa.

Looking at your reply in addition to the previously linked article it is apparent that 1Password doesn't have 2fa because AgileBits decided not to have it rather than for some technical reason.

The risk of data availability We can't back up split keys

Not a technical reason. This is a business reason. People should be responsible when they operate heavy machinery too. When accidents happen it's heartbreaking that people get hurt as well. But that's not a justification to go back to rocks and sticks. People should be aware of the consequences of losing their split keys, but it cannot be an excuse for people that know how to use them not to have that ability.

No reset mechanism

Yes, the stakes are higher. But it's not your place to make the final decision what kind of stakes I'm willing and allowed to take. You still cannot help users if they forget their master password, so it makes no difference here.

Key splitting will be on all platforms or none

This is a business decision and up to you to figure out how to address whatever usability concerns you might have. But that does not eliminate the need to have 2fa.

Let's say I have no interest in mobile devices. Because you have not figured how to implement it for all your environments, I'm left without an additional measure to protect my master db.

Those who need it most are the most likely to be harmed by it

Again, this is your business decision to "protect" those users from themselves. But that does not eliminate the need for a solution.

Yes, the world where 1Password lives is different than TOPT-style authentications. Coming from Apple-centric world I can see why you would have such a mindset of you knowing better than your users. But that does not excuse you from having 2fa. You decided for me that I'm incompetent enough to ensure safety and integrity of my split keys, therefore you limited me and forced me to have my password database without additional security measures.

Thanks for your detailed comments on my comments, @mxxcon. There are plenty of points of agreement, but as you correctly note there are plenty of substantive points of disagreement.

You are perfectly correct that there is a level of abstraction at which encryption and authentication are doing the same thing. They both are designed to allow only certain parties to do certain things with data. I am not trying to deny that. What I am saying instead is that when it comes to discussions of multi-factor authentication, that level of abstraction is not appropriate. My assertion here is not a "business decision", but is a consequence of the technology.

Encryption is about transforming data, authentication is about "letting someone in to something". Authentication systems typically involve encryption in how they do their jobs, but it is the "letting in" versus "data transformation" that makes the difference in these discussions.

Let me see how well github's Markdown deals with tables, as I try to summarize the consequence of these technical differences.

Feature	Authentication	Encryption
(Hashed) password stored	Typically yes	No
password transmitted	Typically yes	No
Pwd sufficient for access	Yes	Copy of encrypted data also needed
One Time Pwd possible	Yes	No
All or nothing for 2nd factor	No	Yes
Resets by admin possible	Yes	No (without key escrow)
Backwards Secrecy	Yes	No

(There are important security advantages of an encryption-based system, but those aren't relevant to the adoption of 2FA or key-splitting; so I'm not listing them.)

Those are not business decisions. Those are consequences of the technical differences between passwords used for authentication and passwords used for encryption. Again, many authentication systems are actually hybrids, and involves encryption. But the authentication portion of those hybrid systems are not the same as the data transformation systems that encryption is.

As I outlined earlier these differences entail different threats and different responses to those threats.

"Business decisions"

Our security design decisions are made in response to these technical realities. I suppose that I should be flattered that you like to call our security design decisions "business decisions". These decisions are about the overall security of 1Password for our customers. I like to think that our focus on security design helps us sell more copies, but I suspect that it might actually do us harm in terms of sales. Most people do not distinguish between encryption and authentication systems, and they do not understand the security advantages of an encryption-based systems (though we believe those advantages are substantial). So it is nice to hear you call customer security our business even when it might hurt sales.

Making choices for users

Coming from Apple-centric world I can see why you would have such a mindset of you knowing better than your users.

We are both after exactly the same thing. We are trying to improve the security for the users of our respective systems. We both want to do more good than harm with any measure we add. We don't allow our users to pick the encryption algorithms and modes for the encryption; we don't allow our desktop users to not back-up their data elsewhere on disk. Likewise, you might try to prevent users from using passwords like "123456" or to log in over HTTP. Systems designers routinely force security choices on their users. You do it, I do it, and it is not at all something to be ashamed of.

This was a nice and interesting discussion to read through.

I can see both sides of the argument in having it on the list; that's why I removed it once and re-allowed it on the site.

However, I'm going to side with removing it from the site for two reasons:

The purpose of the site & 1Password's response.
The conflicting views of what 2FA can be.

Reasoning

When I was making the site, I just wanted a way to view competing products and pick the one that had the best security practices. It was actually a friend, @zdwolfe, that I showed the site to before I released it that came up with the idea. I loved it.

It was a way to let the company know that the customers care about their security. It was a way to socially "demand progress" in the words of Aaron Swartz.

There are some companies that have completely ignored the site. There are some that actually care about it enough to do something about it (most notably @heroku).

1Password has been responsive since the first few tweets. They got in contact with me instantly and sent information to argue why they don't have 2FA.

Disregarding the conflicting definition of 2FA, I think the fact that 1Password has taken the time to respond to all the people that tweet at them as well as having one of their engineers come here to defend their position is evidence that 1Password is looking to the future. They clearly care a lot about how secure their app is (I've read 1Password's articles on PBKDF2 and loved them) so having them listed is really just a nuisance to them.

I trust that 1Password will continue their pursuit of keeping up-to-date with security practices, adding extra security precautions if needed, and continuing to work to make 1Password more secure for me (I use it everyday) as well as others.

Conclusion

So, based on that, I'm going to close this and remove it from the list. Thanks to both of you.

2factorauth / twofactorauth