I RFTM but it seems horribly wrong…

[Deleted User]

Like any good admin (cough), I am making my way through the 1Password for Teams documentation and pushing the buttons as I go. There appears to be a worrying number of discrepancies between what is said in the manual and what the application actually does. Would other users and/or AgileBits gurus care to comment on the following?

▸ The manual repeatedly states that the Shared vault (sometimes also called the Everyone vault) cannot be altered. This appears to be incorrect, as it is possible to remove all users and all groups (all but Owners that is) from the vault, essentially making it disappear from everybody's apps, including the administrator. Is this known and expected behaviour? Personal vaults use a custom view in the Web App, one that makes it clear no permission changes can take place, but the Shared vault displays the same settings as any ordinary vault. Allowing it to be completely hidden from everyone, including administrators all the while forbidding its deletion seems a bit strange.

▸ The notion of Groups appears to be fuzzy. It is currently possible to remove all groups but Owners from a Vault and to set the Owners to "Manage Only" so that, from the perspective of Groups, nobody has read or write access to the vault. Yet, it is then possible to add users to that vault, so that a user belonging to group X has access to a vault even if group X is forbidden from accessing it. Is this expected? If so, what is the point of Groups in the first place?

▸ The manual states that removing a user from a vault results in their being "unable to access any passwords that you change in that vault or any new data that you add to it." This implies that users retain access to a frozen version of the vault they have been removed from. However, in my experience, as soon as a user is removed from a vault, the vault disappears from the client applications. Poof! What is the expected behaviour of this feature?

▸ The manual makes no mention of web sessions that I could find, and yet, I see multiple instances of the same browser listed in my "Authorised Devices." For example, I now have three static icons for the same Chrome browser right how, alongside my OS X and iOS apps. How does one destroy old web sessions and how come they accumulate?

▸ Conversely, I find I am sometimes logged out of the 1Password for Teams web app for no reason. Some sessions last a few minutes, others a matter of a few seconds, even with sustained activity. In this instance, things break horribly: instead of being cleanly taken back to the login page, I notice that buttons stop working or vault icons are no longer displayed. Only a clear-cache-force-reload dance brings proper functionality back.

▸ The manual implies that all members of the Recovery Group can recover any other account. For example, user X with access to no vaults whatsoever (except their own Personal vault) would be able to help an account owner or account administrator regain access to their account, including its full contents and management features. In effect, account recovery ignores all access rights and any team member can help any other team member regardless of their respective position on the access rights hierarchy. Is this actually the case, or am I mis-reading the docs? For example, I see no way to add the Recovery group to any particular vault, so I assume it always has access to all vaults (as far as being able to recover them, that is).

▸ Worryingly, the manual states that a member of the Recovery Group should be able to initiate account recovery from their Admin Console. Yet, my non-Admin user who belongs to the Recovery Group has no such access. So how can this user initiate account recoveries without access to the Admin Console?

rob

Hi, @Deleted User. Thanks for the comments! We are developing 1Password for Teams at a pretty rapid pace, so it's pretty hard for our docs team to keep up with every change, but we're trying.

The manual repeatedly states that the Shared vault (sometimes also called the Everyone vault) cannot be altered.

We just changed the behavior of the Shared vault a couple days ago. (And it was called the Everyone vault until a week or two ago.) We heard from customers that they wanted to be able to change some settings in the Shared vault, so we enabled that. I would personally like to change it so that its name can be changed or the whole thing can be deleted, but those two options are not available at this time. They're still under internal discussion here.

The notion of Groups appears to be fuzzy.

You can say that again. :) Groups are a complexity that we tried to avoid for a while, but it became apparent that we needed more than just users and vaults. There are several things we would like to do there, but there are a few points to make in response to your questions.

First, permissions and access are all additive, meaning if you're a member of a group that doesn't have access to a vault, it doesn't mean that you are banned from having access, it just means that you haven't been given access yet. If someone were to add you to the vault individually, you would have access, whether or not the rest of the group did. Likewise, if your group were added to the vault and you were removed from the vault, you would still have access to the vault through the group. If you were not intended to have access, you would need to be removed from the group, or the group would need to be removed from the vault.

So the point of groups is to allow access to be granted to multiple people at the same time.

The manual states that removing a user from a vault results in their being "unable to access any passwords that you change in that vault or any new data that you add to it." This implies that users retain access to a frozen version of the vault they have been removed from. However, in my experience, as soon as a user is removed from a vault, the vault disappears from the client applications. Poof! What is the expected behaviour of this feature?

Both the information you read and the behavior you saw are expected. If you read my dissertation that I left on the backup thread you commented on, it'll make a little more sense.

Basically, you can't "unshare" information that you've shared. We do all we can to immediately remove the data from the possession of the user, but if the user is not connected to the Internet, "a frozen version of the vault" is a very accurate description of what they have. On the other hand, they could have saved the information a number of other ways: exporting, printing, screenshots, good ole fashioned pen and paper. None of those methods will allow them access to future changes or allow them to push their own changes.

How does one destroy old web sessions and how come they accumulate?

It's not yet possible to remove Authorized Devices from your profile. When it comes to web browsers, it's pretty tricky. We don't control the browser like we control our client apps, so we rely on identifiers saved in the browser's local storage. If that storage gets cleared, the next time you sign in with the browser, a new identifier is created and a "new device" is registered. You shouldn't need to worry about multiple devices showing up at this point unless they are devices you don't recognize. We plan to improve this in the future to allow you to deauthorize specific devices from the web.

Conversely, I find I am sometimes logged out of the 1Password for Teams web app for no reason. Some sessions last a few minutes, others a matter of a few seconds, even with sustained activity. In this instance, things break horribly: instead of being cleanly taken back to the login page, I notice that buttons stop working or vault icons are no longer displayed. Only a clear-cache-force-reload dance brings proper functionality back.

Eww... I haven't seen that. You will be automatically signed out of the web app after 10 minutes of activity, but it sounds like that is not what you're seeing. I actually just pushed some changes last night that we should be deploying this weekend that might help with this situation, though I haven't heard it described this way before. Do you see any error messages when things like this happen? What browser are you using?

The manual implies that all members of the Recovery Group can recover any other account.

Yes, this is correct. Recovering a person's account, however, does not allow the Recovery member to access the account. Rather, when they initiate Recovery on someone's account, that person gets an email with a link they can use to pick a new Master Password and get a new Account Key. Once they've done that, the Recovery member can "Complete Recovery" and the person will have access to their account again.

Recovery members are not able to download vaults they can't access, but they do hold the keys to the kingdom, so to speak.

So how can this user initiate account recoveries without access to the Admin Console?

Interesting, that sounds like a bug. I think we'll have to take this up in an email conversation so I can look at the account and see what I can find. Could you email me at support@1password.com, including your team sign-in URL, your sign-in email address, and the email address of the Recovery member who can't see the Admin Console? Also include my full name (Rob Yoder) in your email so I get notified.

Thanks for your detailed questions, @Deleted User! Let me know if I can help further. :)

rob

@Deleted User never mind about the email, I see what the problem is. It just came up with a recent change to our web app permissions. I'll get an issue open so we can take care of it, thanks!

ref: B5-1125

[Deleted User]

Hello, @rob!

I quite understand how difficult it is to keep the docs perfectly up-to-date, no worries. If end-users like us can lend a hand, do let us know. Maybe we can contribute texts based on our experience with the apps, as well as your excellent replies in the forums, to be edited and reviewed by your team, instead of written from scratch?

We just changed the behaviour of the Shared vault […]

We'll just take it in stride, then. The current behaviour, whereby it can be hidden from everyone but not deleted, feels very idiosyncratic but it is by no means reprehensible.

Count me amongst your customers who have no use for the Shared Vault and even find it cumbersome. In fact, we need none of the default vaults, Shared or Personal, and having them in the way feels unnecessary. It's great that they are created by default, since they should answer the needs of most users, but do add my vote in favour of making them optional, for the many reasons mentioned elsewhere in this forum.

Groups are a complexity that we tried to avoid for a while

Point taken about the Groups. This makes perfect sense. I would be tempted to point out, however, that neither the UI nor the docs make this clear and that I can foresee a lot of users leaking out sensitive data because of this. My UNIXy side wants to scream that they are not Groups, they are ACLs…

The behaviour you describe sounds perfectly fine, but I believe it would pay to revamp the UI to make it clear that permissions are always additive.

Maybe the easiest way to do so is to merge the "Groups" and "Users" sections, and to add a big plus sign somewhere in-between. (Sounds cheesy but I wish you could see how classy and intuitive it looks in my mind… :p)

Another option would be to list all the users who effectively have access to a vault, stating "Added individually" or "Added through their Group" underneath each entry.

If you read my dissertation

Your dissertation is of the utmost clarity. In fact, it should be the documentation. The current docs would benefit from being tweaked to state unequivocally that vaults do disappear but that it is impossible to guarantee that someone has not somehow retained backups of the information.

The current aphorism about un-sharing secrets sounds great but it seems to introduce a good deal of confusion. (I notice now that I am not alone in having asked the question and I do apologise for piling it up.)

We plan to improve this in the future to allow you to reauthorise specific devices from the web.

This is without a doubt what happened: I clear my browsing data on a regular basis, so multiple instances of the same browser must have remained authorised. Yes, being able to purge them would be good, if only to keep the logs trim and readable.

Eww... I haven't seen that.

I am using the latest Chrome (48.0.2564.116 at the moment) and see no particular errors, either in the app or in the Console. It just breaks at some random point in the session. I'll give the updated version a spin and report if the phenomenon persists.

Never mind about the email, I see what the problem is

Awesome! Feel free to email or DM me if you need any extra information. The Recovery system is very powerful, but it really needs to work smoothly if 1Password for Teams is to be trusted, and I am surprised the developers did not notice. Would a box of French brownies (no doubt noted the world over for their… something) convince them to add a Recovery unit test to the pre-release checks?

Mitch

Hi @Deleted User.

Thank you very much for your feedback about the 1Password for Teams documentation. As @rob explained, Teams is a moving target, so the UI and even some behavior can diverge from what we have written down.

Our current challenge is the need to write documentation that's suitable for the new Family accounts. Sometimes the same article is appropriate for both types of accounts, but sometimes the differences really matter. So we need to do some reorganization to make sure families can find they are looking for.

That said, expect to see a fresh set of admin guides this coming week. We'll be taking feedback from you and others into account. Keep holding us to your high standards. :)

rob

Thanks, @Mitch!

In fact, we need none of the default vaults, Shared or Personal

@Deleted User, I don't think the Personal vault is going anywhere any time soon, but who knows. At this time, it's not possible to create another vault that only you have access to (unless you're the only Owner). All new vaults that are created are given to the Owners group to manage and that access cannot be revoked. Personal vaults are not listed in the vaults an Owner can manage, however, though they are recoverable along with everything else. It would be interesting to be able to create multiple "Personal" vaults.

My UNIXy side wants to scream that they are not Groups, they are ACLs…

That's just a slightly more obscure name for non-UNIX-admin-people. ;)

Another option would be to list all the users who effectively have access to a vault, stating "Added individually" or "Added through their Group" underneath each entry.

This is something we will be doing. It's been on my list for a while, but it's just complex and will require changes to many pieces. For example, if someone has a vault through a group, we can't allow that person to be individually removed from the vault. Either they should be removed from the group or the group should be removed from the vault. Same goes for permissions within a vault. The user might have Manage access through the Owners group but full access individually. Well, their Manage access can't be individually revoked as long as they're a member of the Owners group.

So things like that have kept things confusing and it's going to take a concerted design+development effort to correct them. But you are right, and we know it. :)

I am using the latest Chrome (48.0.2564.116 at the moment) and see no particular errors, either in the app or in the Console. It just breaks at some random point in the session. I'll give the updated version a spin and report if the phenomenon persists.

That'd be great. I haven't heard of any issues like that, so I'd love to see steps to reproduce it if you come up with them.

The Recovery system is very powerful, but it really needs to work smoothly if 1Password for Teams is to be trusted, and I am surprised the developers did not notice.

Very true. In this case, the issue only affects Recovery members who are not also Owners or Admins. While that's not rare, it wasn't on our radar as being different enough to test for each release.

Would a box of French brownies (no doubt noted the world over for their… something) convince them to add a Recovery unit test to the pre-release checks?

This made me laugh audibly. Unfortunately our geographically distributed team makes this a much less promising incentive. Maybe we can sync up on that the next time I schedule a trip to Toronto. ;)

[Deleted User]

Hello, @rob! Thanks again for your kind reply. :)

At this time, it's not possible to create another vault that only you have access to

Hmm, this is interesting. Being the only owner, I had not realised that such was the case. This will not be a limitation for us, but I see how it could throw some teams off-balance.

My concerns with the Personal vault echo what most users have said already: they could create confusion and lead to nominally shared credentials being stored in the wrong location, resulting in frustration and administrative difficulties. Nothing major, certainly, but an issue that might be best avoided by an upstream policy change.

Making these users "Guests" could solve the issue of these extraneous Personal vaults, but at the cost of not being able to add them to the Recovery group, which I feel is too high a price to pay.

It's been on my list for a while, but it's just complex and will require changes to many pieces.

Oh, yes, I have no doubt that every single change is actually quite complex. Whenever I say "simply" or "just" or "merely," I do not wish to imply that this is something that could be done in a second. Rest assured I have the utmost respect and admiration for your skills and your hard work.

I haven't heard of any issues like that, so I'd love to see steps to reproduce it if you come up with them.

You'll be glad to know that I have not bumped into that issue since you implemented the fix you mentioned. I was logged out once, but it happened cleanly, after 10 minutes, and with a nice error message to boot. :+1:

In this case, the issue only affects Recovery members who are not also Owners or Admins.

There is a lot of value in such a setup, since it enables a kind of peer-to-peer safety net which can be cast all the more widely that users need not be vetted in the way Admins are. Instead of one or two points of failure, one can rapidly grow to dozens, including team members to whom one would not hand out any privileged information.

This feels like a key feature of 1Password for Teams, in that it almost (but of course not quite) makes the Emergency Kit irrelevant, provided the Recovery group remains staffed at all times.

Maybe we can sync up on that the next time I schedule a trip to Toronto.

It's a deal! We'll ask @roustem to choose a good bakery and we'll make it happen. :chuffed:

rob

@Deleted User

Understood, regarding the Personal vault. I can't promise anything there (we haven't really discussed it here), so all I can give is the political "we'll take it into consideration." But really, we keep re-evaluating everything, so I won't be surprised if we make changes there in the future.

You'll be glad to know that I have not bumped into that issue since you implemented the fix you mentioned.

Great!

There is a lot of value in such a setup, since it enables a kind of peer-to-peer safety net which can be cast all the more widely that users need not be vetted in the way Admins are. ... This feels like a key feature of 1Password for Teams

It is indeed a very key feature. I think we're cautious about recommending a very large Recovery Group, however. While we do our best to prevent any malicious shenanigans, the truth is that Recovery is a high power. With the keys to everything, the only thing preventing Recovery members from doing bad things is server policy that refuses to give them the actual data if they only have Recovery access.

When dealing with services like this, we have to consider all the worst-case scenarios. Imagine a criminal steals the unencrypted laptop of a top executive. Maybe the criminal can't crack the executive's Master Password, but he can target a Recovery member with a weak Master Password. Now he has the data and the keys.

Anyway, I'm not trying to be scary or overly conspiratorial, these are just the kinds of things we're thinking about as we make decisions. Hiding the Admin Console for Recovery-only members was an accident, not a decision, but I'm speaking in terms of documentation and education, the things we are trying to convey.

[Deleted User]

All I can give is the political "we'll take it into consideration."

No worries at all. I am certainly not expecting any commitments. It is, in any case, a point of detail.

Recovery is a high power. [T]he only thing preventing Recovery members from doing bad things is server policy that refuses to give them the actual data

Eek, that is scary, now that you put it in this way.

[W]e have to consider all the worst-case scenarios

Definitely! Considering these scenarios is of the essence. We would none of us be using a password manager if we thought worst case scenarios where the stuff of spy movies.

Maybe the criminal can't crack the executive's Master Password, but he can target a Recovery member with a weak Master Password. Now he has the data and the keys.

Practically speaking, how would such an attack unfold? I'm not sure I have my mind sufficiently wrapped around the inner workings of 1Passowrd for Teams to picture it. I'd like to know what the worst case scenario is, here, so that we can develop smart grouping policies. I appear to have under-estimated the dangers and I'm glad you're calling me out on this. :)

rob

I appear to have under-estimated the dangers and I'm glad you're calling me out on this.

@Deleted User, I do want you (and everyone) to be able to make informed decisions when it comes to security policies and how you manage your team account. On the other hand, I don't want to list so many obscure threats that you or anyone else reading is scared into a setup that isn't really helpful or practical.

We try to take all the threats and boil them down into some best practices that we can recommend. In this case, we're talking about a balance between the threat of a spy-movie-like attack against your team and the threat of data loss by being locked out of an account. To protect against data loss, we recommend at least two people have Recovery ability. How much you limit Recovery will depend on your team.

I realized just now that I exaggerated the threat in the scenario I mentioned. The Account Key helps us a lot here. If someone were able to get encrypted data from an authorized device, they would likely be able to get that user's Account Key as well. But that would only help them in a brute force against that user's Master Password. Since the Master Password and Account Key are used together to derive the keys, the thief would not be able to brute force another user's Master Password without also having their Account Key, which would require another theft of some kind.

If you'd like to learn all you could possibly want to know about the inner workings of the system, you'd really enjoy reading our white paper on the Security Design of 1Password for Teams. Besides technical stuff, there are also dogs, a cat, a leopard, and probably some other animals in there. :)

[Deleted User]

Hello, @rob! :)

I appreciate your concern. I am definitely not tasked with defending anybody against the NSA but knowing how 1Password would help in such an extreme scenario can help understand it better and, ultimately, make sounder decisions. Please don't shield us from paranoid narratives: far from scaring us, they will help us make better decisions as administrators. (And we may need to defend our users against the FBI pretty soon if the current kerfuffle is any indication…)

Maybe I should reframe this in a more mundane way. Let us imagine that one of my Team Members who belongs to the Recovery Group has had his devices stolen, and that these devices were not encrypted. What steps should I take, as an administrator, to safeguard our 1Password for Teams data, both his and the data of other users? I imagine changing his Master Password is a given, but what else?

It would be helpful to have a few "emergency" support documents covering such cases, but maybe you would care to elaborate in here until they are written? (An even better option would a feature similar to Facebook's /hacked that walks you automatically through all the steps you need to take in a panic.)

rob

It would be helpful to have a few "emergency" support documents covering such cases

@Deleted User, indeed, I think that would be good as well.

Let us imagine that one of my Team Members who belongs to the Recovery Group has had his devices stolen, and that these devices were not encrypted. What steps should I take, as an administrator, to safeguard our 1Password for Teams data, both his and the data of other users? I imagine changing his Master Password is a given, but what else?

I have a pretty good idea of what should be done in these cases, but we're moving out of strictly implementation details and more into questions of operational security. We have a great security team here who are all a bit more qualified for these kinds of questions, so I'll see if one of them can chime in soon. :)

rob

@Deleted User, ok, I ran my thoughts past @julie-tx and got them confirmed. So you get me again. :tongue:

What you get by stealing a device

Basically, encrypted data and the team member’s Account Key. This is true for any team member, Recovery member or not. If an unencrypted authorized device is stolen, you have to assume that the Account Key is compromised and that the encrypted data is available to the attacker. At that point, it's a battle against the Master Password. If it's a strong Master Password, the attacker may never get in. A weak Master Password could let him in pretty quickly.

Once an attacker has the device, you can no longer do anything to protect the data on that device. Your trust rests in the Master Password that the team member used. Your next steps are to render the data and the team member’s sign-in credentials as worthless as possible.

Preventing live account access

Assuming the attacker is able to crack the team member’s Master Password and gain access to the data on the device, there are other steps you can take to mitigate further damage.

First, render the attacker's newfound credentials useless by changing the Account Key. The only way to change the Account Key right now is to perform Recovery on the team member’s account. Recovery is based wholly on the security of the team member’s email address, so there are some precautions to take.

1. As soon as the device is stolen, suspend that member’s 1Password account.
2. Secure the member’s email address. If your team controls the email address associated with the member’s account, you could reset the password, making sure (in person, via phone call, or using some other verifiable means) that the person setting the new email address password is actually your team member. In person is of course the best option. If you do not control the email address, the team member should reset their own password through whatever means are available.
3. Once email is secured, you can reactivate the member’s 1Password account, and then begin Recovery of the account. They will receive an email which will let them get a new Account Key and set a new Master Password.
4. Once they've completed the process, you'll get an email stating that they are ready to have Recovery completed. Once you complete Recovery, they'll be able to sign in again with their new credentials and re-authorize their remaining devices.

Once the member’s account is secure again, you'll want to go through all the vaults they could access and begin changing the passwords for those accounts. If the attacker was able to crack the Master Password, they will have access to all existing information on the device, even though they won't be able to sign into the account or access new information.

Usefulness of the Recovery key set

I keep realizing (happily) that there are more roadblocks to a Recovery-member attack.

What gives Recovery members their power is that they get a copy of the Recovery Group key set encrypted with their own personal key set. In turn, the Recovery Group itself has a copy of every other key and key set in the team encrypted with its key set. The catch is that all these encrypted copies are stored on the server, and they remain there until they are needed for a valid Recovery process.

So the worst case scenario also requires a server attack:

An attacker compromises our server, getting access to the entire database
and obtains the server-side key that encrypts the whole database
and is able to acquire a Recovery member's Account Key
and crack their Master Password.

If all those things happen, the data across the entire team is compromised because the attacker will be able to decrypt the Recovery key set, along with all the vault keys, and thus all the data encrypted with those keys.

That's a tall order, though. If the server is not compromised, there's actually no way for the attacker to do anything special with the Recovery member's personal key, assuming you've secured that member's account as previously described. So the attack becomes the same as that for any other team member.

There's another essay for you. Hope it helps! :)

[Deleted User]

Hello again, @rob! :) Thank you for the essay, it most definitely helps a very great deal. This is all essential information, that really should be publicised much more widely than this thread allows for. And I would definitely vote in favour of an emergency button that walks administrators through all these steps, because that is a lot to think about in a panic!

If the server is not compromised, there's actually no way for the attacker to do anything special with the Recovery member's personal key, assuming you've secured that member's account as previously described.

This is extremely reassuring, and I agree that all the conditions you list above for a recovery attack to succeed place it definitely out of the range of things to worry about when a phone gets swiped by a random pick-pocket.

The Recovery Group itself has a copy of every other key and key set in the team encrypted with its key set.

One important follow-up question, if I may…

How often are these keys rotated and how do they propagate? For example, let us imagine that I have set up all my users, all their vaults, and all my groups, including Recovery. Then, at the eleventh-and-a-half hour, I add a new user to 1Password for Teams.

Can other Recovery members immediately recover their account? Conversely, can they start recovering other accounts right away? Or do I need to re-jig the Recovery group permissions, for example, for the keys to be reset?

julie-tx

@Deleted User -

Documenting what Rob wrote and making sure your team is aware of it is part of making that "Emergency Button."

What we have is a vault named "Emergency Vault" which is being filled with sections from our Disaster Recovery Plan. This way if there is an emergency the person who's having the emergency can just go to the vault, find the Secure Note which has the right title ("Lost or Stolen Device" in this instance), read the steps, and off they go. In our case, we have three emergency contacts listed who are able to disable managed resource access, and three other contacts who are able to perform the recovery.

To answer your follow-up question, as soon as a user is fully activated they can be recovered. There's no time delay.

[Deleted User]

Hello, @julie-tx! Thank you for your kind reply and these extra details. Thanks also for working with @rob earlier. :)

I agree that writing our own documentation would be good, and I like your idea of creating a vault dedicated to such data. Nevertheless, I hope this would not take a back-seat to AgileBits implementing some kind of assistant to help us administrators in our hour of need. (Even though I understand this cannot be a priority for you.) Facebook's /hacked URL is really a wonderful example, and so is Google's comparatively newer "Secure your account" button.

Am I to understand from your reply that AgileBits trusts 1Passwords for Team enough to (really) run its own business on it?

julie-tx

@Deleted User -

AgileBits has been using 1Password for Teams to store critical business credentials for quite a while, and we use it in our personal lives as well. For example, all of my personal financial information is in my 1Password Families account, including information which would allow someone to break into my house, turn off my burglar alarm, and rob me blind.

Not only do we use it to manage our most important secrets, but we've also described its inner workings so that you can understand how it works. And should you read that document and understand how it works in detail, we still trust it to keep our secrets secret.

[Deleted User]

This is all pithily and colourfully expressed! :+1: Thank you for the extra details!

Jacob

On behalf of the awesome team, you're welcome. It's been a great conversation. :+1: :)