12

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

16

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.

  • Thanks for your clarification about the 1Passoword Team. I am sure that all of you in 1Password make a best effort and work to keep the security of the online passwords in the top level. And I general the 1Password in Mac os runs like a charm (except of the general lag with the 1password mini - that u already know about it). However, my question was to clarify these security things because as you can image it is an online service and things may go wrong anytime. – Greg Mar 1 '16 at 5:12
  • We absolutely love getting questions. Certainly "anything" can happen, and with an online service it's important to understand the full range of "anything". We also need to understand what sort of things may go wrong anytime you're worried about. If there are specific concerns, please let us know and we can walk you through how we protect you in that specific instance. – Julie in Austin Mar 2 '16 at 12:46
  • So where is the Account Key stored? Does it lie around plain-text on every device? This is the first question that sprung to my mind but so far I didn't find any information about it. If it's not protected in any way, then it doesn't improve security by much? – enzi Dec 29 '16 at 16:06
6

[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.

  • So where is the Account Key stored? How is it protected? If it is not, isn't all the extra security gained by it lost rather easily if it is compromised? – enzi Dec 29 '16 at 16:09
  • @enzi, the Account Key is stored unencrypted on your local device. So it offers no protection if data is stolen from your device. But it offers enormous protection if data is stolen from our servers. – Jeffrey Goldberg Jan 1 '17 at 7:11
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).

  • So, u said in other words that due to the fact they dont store the Master password everything is fine with the encrypted passwords in their database. Of course, we speak for situations that any member of the team dont use a compomized PC and everyone is secure aware. – Greg Feb 27 '16 at 20:45
  • But the problem is how someone can trust their database? I think that a user can trust his/her pc but their servers? This is a discussion about zero-knoledge trust as you can image. zero-knowledge trust -> Each user of the team trusts them without know if their system is vulnerable. There are historical examples with the online password managments that they leaked encrypted passwords. (see the link in my question) – Greg Feb 27 '16 at 20:49
  • 3
    By the way, I have just found that they dont provide any offline backup for the 1Password Team accounts, and every team should rely on their backup plan. I dont blaim for leaking information or losting encrypted account due to the non-offline backup, but at least with a personal account, and just sharing the Vault the things are more stable. – Greg Feb 27 '16 at 21:43
  • 1
    @Greg - It's true that 1Password for Teams is still in beta, but the 1Password Families product, which is built on the 1Password for Teams platform, is in production at this time. – Julie in Austin Feb 28 '16 at 18:05
  • 2
    "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." Just to let you know, the various 1Password applications (other than the web app) store a copy of your data locally. We will never lock people out of their own data. – Jeffrey Goldberg Feb 29 '16 at 18:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.