Is 1Password for Teams less secure

pahidla · February 2016

Hi,

I have historically pitched 1Password (not for teams) to my colleagues saying that no information (encrypted or otherwise) is stored in the cloud. Am I no longer able to make the same claim for 1Password for Teams?

Thanks!

PG

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

[Deleted User] · February 2016

Since, by definition, 1Password for Teams is all about cloud storage, distribution, and synchronisation, it is indeed no longer possible to claim that no information, encrypted or otherwise, is stored in the cloud.

1Password for Teams may, of course, fall prey to bugs, silly or otherwise, and it still needs to prove itself, especially since AgileBits has no demonstrable experience managing web services. Paranoid scenarios could certainly be envisioned as part of which the company is forced to booby-trap its own applications or servers to compromise their users, but that would be true of any update to 1Password, with or without cloud storage — or, for that matter, any app or operating system we already rely on.

My understanding is that AgileBits designed 1Password for Teams so that they know as little as possible, which explicitly excludes knowing your passwords, keys or vault contents. In this light, even though the data is indeed stored in the cloud, they should be unable to access it, much like Dropbox is currently unable to access the contents of any 1Password database stored on their servers. And since no two clouds are created equal, it should also be pointed out that they have optimised their server stup for security, which may not be the case of other more generically-minded storage companies.

The new "for Teams" offering does change the security model but I would trust AgileBits to have gone to great lengths to protect the data. In fact, they have published a white paper that shows precisely how far they have, and I would call their precautions more than satisfactory (in theory, at least).

Finally, it should be noted that 1Password for Team is neither compulsory nor the "next generation" of 1Password — at least it was not announced as such by AgileBits, and they should now. It is merely an option for those teams that already used 1Password's existing cloud syncing options and require more advanced functionality.

I would argue that you can keep on recommending 1Password to everyone: users who have no interest in cloud storage can safely ignore it and those who are tempted to try it out can do so with the confidence that they've got the best possible cloud — as far as meteorological systems go, anyway.

jpgoldberg · February 2016

Thanks, @pahidla and @Deleted User!

Indeed, you are correct that with 1Password for Teams or Families we do hold your encrypted data.

It's your choice

Of course you can still use 1Password without making use Teams or Families, in which case we would still never see any of your encrypted data.

You can also mix and match. You can have some vaults that are not part of Teams or Family and others that are.

Changing security model

@Deleted User is absolutely correct that Teams involves a new security model for us. It means that we must defend against threats that previously we didn't have to worry about. As you can imagine this is not something that we took lightly. Indeed, there are some specific things that we have done and planned from the outset to address our (and presumably your) biggest concerns.

When we build a system in which we host your data we have to build it so that

It doesn't get broken into, and
When it gets broken into you are not put at any risk.

We have to design with the expectation that it will be breached because good security design requires a pessimist. (Before we settled on my job title, I was internally known as "Worrywart in Chief".)

1. Two-secret Key Derivation

Imagine a breach in which all of the data we store is captured. For many systems there would be hashes or keys derived from a user password among the stolen data and so the attacker could run a password cracking attack against that. If they succeed in that password cracking attempt then with that password (and some other non-secret data such as salts, etc) they would be able to decrypt the stored user's data. That would be bad.

The “traditional” defense against this is to use slow hashing during key derivation. We were among the first password managers to use PBKDF2, and now it or some other slow hashing mechanism has become a pretty standard feature. It's good, it is important, we still do it; but it may not be enough. It slows an attacker down; but it doesn't entirely prevent Master Password guessing attempts.

What we've done is introduce what we are calling “Two-Secret Key Derivation (2SKD).” We mix your Master Password together with a high-entropy secret that only you possess: your Account Key. Your Master Password is one secret that lives only in your head, but is potentially guessable; and your Account Key is a completely unguessable secret that lives only on your devices.

What this means is that even if all of the data from our server is captured, there isn't enough data there to even launch a cracking attempt. Without your Account Key, there is no way to even begin to guess at your Master Password.

Quite simply, we didn't want to be storing information that would be valuable to any attacker.

2. Secrecy preserving authentication

It's not just that we don't want to store information that could be used to launch a cracking attempt, we don't even want to be in a position to acquire such information.

On typical website logins, a user secret (password) is transmitted to the server. Even if the server doesn't store the password (but only a password hash), the server has the opportunity at that time to learn the password.

Better systems will have some password hashing of the secret done by the client before transmitting, and then it will be further hashed by the server before being stored. This way the server wouldn't get a change to steal the password directly. But the hash that they are sent could be used for a password cracking attempt. So while this is better than the typical system it is not enough.

We use a Password Authenticated Key Exchange (PAKE) that means that no secret is transmitted during login. Not even a hash of a secret. The information that we acquire during a log in session gives us nothing that we could use to try to guess at your Master Password or Account Key. The particular PAKE we use is SRP.

So not only do we not store anything that can be used to in an effort to learn your secrets, but we've even set things up so that it would be hard to acquire such information.

Why these matter

The very legitimate concern many people have about storing their data on someone else's computer is that either those hosting the data will be compromised or that they themselves will do something with the data that you would rather they don't.

There is no cloud. It's just someone else's computer

So what we building a system that keeps you secure against us. It's not that we are worried that we will turn evil or anything, but it is the simple fact that if you are secure against us then you are secure against anyone who compromises us.

Models change. Principles don't.

Now 2SKD and SRP aren't the only things we've done to protect your security against an attack against us, but they are two things that I think illustrate how we have stuck to our principle of not being in a position to know anything about you even as we've moved to this new model.

AGAlumB · February 2016

@pahidla, @Deleted User: And while I love Goldberg's detailed explanations, I also wanted to reiterate what I think is the most crucial and yet simplest aspect of 1Password for Teams/Families:

Since we never have the means to access it, we effectively don't have your sensitive data — and therefore no one else can get it from us either. Both your Master Password and Account Key are needed to decrypt your 1Password data, and neither are ever transmitted, so they are never in the possession of AgileBits, nor can they be intercepted.

So while we store (and backup!) the encrypted blob on our servers so it can be transmitted to your devices for you to unlock and access your vaults, that's all we have, and it isn't of any greater use to us than any other random noise on disk. And if you lose your Master Password and/or Account Key, you won't be able to access your data either*. That's how secure it is. :sunglasses:

*Except other members of your team with Recovery access can reset it for you securely, which is something awesome that was never possible with the standalone apps. It's a different kind of security ("Oops! I forgot it!") that's made possible through "Team-work" and "Family-planning". ;)