1Password for team how secure it is?

Question

I would like to ask you opinion about how secure is the 1Passowrd for Teams.

For someone who doesn't know how 1Password - Personal use - works here a summary: You create a master password (hard to bruteforce it) and you encrypt all you other credentials with your master password. Everything is saved locally and noboby except of you and who ever uses your PC can access the encypted passwords. Safe and secure indeed.

However, in the case of the 1Password for Teams there is something completely different. Every encrypting passoword stored online if I can understand well.

So here a summary as well:

First of all, you setup a domain in which all the team is above this. 1Password web-server creates automatically an Account Key. Also, they say that they dont save this Account Key password.

Additionally, the creator who is the administrator of the team setups his master key.

Later, the admin sends an invite to a member by using his email. The new member, click on the invitation link and 1Password creates him a different Account Key and after that this member creates his master account.

The actual problem is that WHERE all this encypted password as stored ?????

As I can imagine ALL the Shared and the Personal encrypted passwords are stored in 1Password Database. Am I correct??

How secure it that even if it is encrypted ?

If every encrypted passwords was locally, everyhting was more secure, but with online storage even if it encrypted? Should everyone who use the 1Password for Team should be cared about a hacking incident like the hacking on the LastPass? LINK

Answer 1

First, a brief disclaimer. I work for AgileBits, the creator of 1Password, on their security team.

1Password for Teams, as with most password managers, makes use of a "master password", the password which grants access to all of your other passwords, to create an encryption key. That encryption key is then used to encrypt everything else you store.

Unlike other password managers, it makes use of an additional secret - a 128+ bit randomly generated "account key". The Master Password and Account Key are used to perform 2-Secret Key Derivation, in which the "master unlock key" (MUK) -- the key which protects all of your passwords -- is based on the entropy from both of those. So, if your Master Password contains 60 bits of entropy -- which isn't particularly high, but is a nice example value -- the MUK has at least 188 bits of entropy.

AgileBits has access to neither of those values - we don't have your Master Password and we don't have your Account Key. None of the random numbers which are used as encryption keys are ever generated by AgileBits either, so we aren't in a position to have any of your encryption keys.

To the point that was made in an earlier answer, even if your Master Password is disclosed, the Account Key must still be obtained, and it provides over 128 bits. This means that an attacker must make 2^127 trials, on average, to guess your Account Key. In short, if I told you that my Master Password is "fast cars are fun", you'd have an insurmountable computation - enumerating 2^127 possible Account Key values - ahead of you. Just that step - enumerating 2^127 possible values - is beyond the capabilities even of State actors (governments).

Being that secure has its downsides, and we have created a mechanism which protects you from us, and us from attackers, and minimizes the risk that you will lose all of your information. Because we don't have any of the secrets required to access your information, we cannot "reset" your password or allow you to create a new Master Password if you've forgotten it. This prevents us from abusing a "password reset" mechanism and gaining access to your information, whether for our own advantage or at the behest of a government entity. And if we can't get to your secret information to abuse or disclose it, hackers are going to leave us alone (so the theory goes) because they also cannot get your secrets from the data we have.

Our innovative solution to the "password reset" problem is called the Recovery Group. The Recovery Group is one or more members on your team who have encrypted access to all of the encryption keys used by the various team members. We also don't have access to the encryption keys used to encrypt the recovery keyset, so we can't abuse that either.

Not only can we (or an attacker) not gain access to your encryption keys, we cannot gain access to the mechanism needed to restore access to those keys, if a user loses their Master Password and/or Account Key.

For more information, please read our security page. It also links to the security design white paper which includes significantly more information.

Answer 2

[Disclosure: I work for AgileBits, the makers of 1Password]

In your question, you said

Password web-server creates automatically an Account Key.

Although it might appear that that is what happen, closer inspect of the client (and some of our documentation) will let you know that the Account Key is created by your client and not on our server. No keys are generated by our server.

So not only do we not store such keys, we have built things so that we don't have the opportunity to store such keys.

Two-secret Key Derivation

As my colleague, @julie-in-austin, explained in her answer, this Account Key is part of our Two-secret Key Derivation (2SKD). The other secret is your Master Password. Both secrets are needed to derive the keys that are using to decrypting your data. Neither secret is ever seen by us.

The major point of 2SKD is to protect you even if our servers are compromised. Obviously we aren't planning for our servers to be compromised, but we must plan in case our servers are comprised. Without 2SKD your data could be used by an attacker to launch a Master Password guessing attack. With 2SKD such an attack is impossible.

A bit of history

We have long taken the attitude that we don't want to hold your data in any form whatsoever. We can't lose, use, or abuse data that we don't have. Not having sensitive customer data means that there really isn't anything worth stealing from us. So when we wanted to offer the kinds of secure and flexible sharing (sorry for the sales pitchy talk, but these were capabilities that we really wanted to add), we struggled with how to do it while keeping no customer data. (Yes, there are peer-to-peer protocols we could have developed, but it would have added substantial complexity for users and would have had to defend against a whole other class of attacks.)

So two things were in our design for Teams from the outset. First, hold nothing "crackable". Second, learn nothing "crackable".

We've used defenses like PBKDF2 for a long time to offer some substantial cracking resistance to captured data (and that is still the case today). But eventually we run up against a wall of diminishing marginal gains in security from increasing such things. We wanted something that mean that what we hold onto is worthless for cracking attempt. As Julie said, the Account Key (which never goes near our server), means that an attempt to guessing your Master Password based on data we hold is not limited by the strength of your Master Password, but faces a 128 bit challenge from your Account Key.

The second part of this is that we didn't want to even be in a position to acquire anything secret during the authentication process. So we use a Password Authenticated Key Exchange (PAKE) protocol during login. Neither us (or anyone who may have gotten past the secrecy provided by SSL/TLS) can learn anything usable during login.

So from the earliest planning sessions through what you see know were ways to ensure that you are protected even if we are compromised. This is beyond the usual (and still useful) mechanisms of things like PBKDF2.

Answer 3

1Password is just a password manager, but with an online option. It also allows to store additional information into it like software licenses and other types of authorizations. You can store just locally, or sync with an online repository.

The encrypted passwords are stored at 1Password's site. If information stored online is properly encrypted, it's pretty save, as long as the access password is not compromised.

This system has a single point of failure (SPOF), if you lose this master password all passwords are compromised. However, it can also improve your security, if it simplifies the good habit of not using the same password all over at every web-site.

Notice that the usability and price of this service is a completely different issue. If a site changes its API, you'll have to tweak the login data to be able to login again. And you'll still need a local copy of your passwords, just in case this service goes bust. There are also other options to manage passwords (some are free).

And this service can't protect against your password being stolen when using a compromised computer. So, you'll still need to carry some device with you if you want to connect safely. (I emphasize last paragraph, take care, SPOF here).