Recovery by Team Members

[Deleted User]

Dear all,

While adding a new Member to my account today, I noticed a nice little yellow call-out in the right hand side column urging me to add more Owners and Administrators to ensure user accounts could be recovered in the event of an emergency. This echoes the 1Password documentation which, if memory serves me well, repeatedly states how important it is to have multiple admins on an account, for these reasons precisely.

However, I notice that 1Password automatically places all account users in a Team Members group, to which the Recovery privilege can be assigned. This makes it look like it is in fact possible to grant Recovery privileges to all members of a team without the need for extra administrators and without the need to manually "bless" users with this added privilege each and every time they join.

What am I missing here? Is it unsafe to grant recovery privileges to all the members of a team? Are these recovery privileges "fake" or limited and would a regular member of the Team Members group be unable to help an Administrator recover their account if needed? If so, why does the web application make such an arrangement possible?

My understanding of the Recovery procedure is that is necessitates approval from both parties: both the person kick-starting the recovery procedure and the person being helped. Furthermore, my understanding is that the Recovery process would never allow a low-privileged user to peek into the vault of a high-privileged user even if the former were to help the latter recover their account. In that light, there seem to be very few downsides to allowing everyone on a team to help everyone out. I do, however, feel that I am missing something obvious and dangerous… :dizzy:

Any insights would be most appreciated, especially since Recovery is a crucial topic. :chuffed:

— FJ

Ben

Hi FJ,

While you certainly can give all Team Members recovery access, I would caution you against doing so. While there are a number of mechanisms in place to prevent them from actually using them, people who have recovery powers also have all of the decryption keys. This is essential in order for them to be able to perform recovery. I'd recommend reviewing the section of the white paper titled Protecting vaults from Recovery Group members.

While there are technical measures in place to protect the team from a malicious or compromised recovery group member there is still a level of trust required, and as such I'd encourage prudence.

Thanks!

Ben

AGAlumB

@Deleted User: While Ben's answer is much more complete, I did also want to point out that there's an "annoyance factor" (for lack of a better term) which could come into play. Any team member with recovery permissions could start the process for others whether they request it or not. So in larger teams you may see instances where this is misused, perhaps innocently, and causes headaches for team members. Just a thought.

[Deleted User]

@Brenty — Thank you, the annoyance factor is indeed a consideration. I do not think it would apply to the team which I am currently managing, but that is certainly worth keeping in mind.

@Ben — This is indeed not something to be taken lightly and I admit that I had not realised that granting Recovery permissions entailed relinquishing the keys to the castle to such an extent. Could you tell me a little more about the worst case scenario should a member with such powers be hacked and compromised? I am especially curious about this sentence, which I find difficult to parse: "A member of a recovery group will only be sent the encrypted vault keys after the user requesting recovery has re-created their account." What does the latter part mean? Shouldn't it read something like "after the user requesting recovery has confirmed their desire to proceed with the recovery by clicking on the link contained in the confirmation email?"

AGAlumB

@Deleted User: Sure thing! It sounds scarier than it really is, but I think Ben's point is that it does grant people a certain power. I can't really put it much better than the extensive coverage of the risks outlines in the white paper, but I did want to address this:

I am especially curious about this sentence, which I find difficult to parse: "A member of a recovery group will only be sent the encrypted vault keys after the user requesting recovery has re-created their account." What does the latter part mean? Shouldn't it read something like "after the user requesting recovery has confirmed their desire to proceed with the recovery by clicking on the link contained in the confirmation email?"

That's correct, but it is a bit difficult to parse. I'm just not sure that there's a better way of saying it. It's true that the encrypted vault keys are only given to the recover-er after the recovery is completed by the recover-ee. These are only available after they're generated when the account is re-created. I find it helpful to think of it in terms of public key cryptography, which works similarly. And, at the end of the day, the most important thing to keep in mind is the following, from right above "Protecting vaults from Recovery Group members":

Recovery Group members never have the ability to learn anyone’s Master Password, Secret Key, Master Unlock Key (MUK), or SRP-s. Recovery is recovery of the vault keys; it is not recovery of Master Passwords nor Secret Keys.

Edit: Apologies. Fixing up the end of my post here shortly, as the forum ate part of it...

AGAlumB

@Deleted User: (continued) So the real risk here is the ever-present human threat to security, since we're the weakest link to start and can make mistakes. Giving everyone recovery permissions means increasing the pool of potential targets who could be tricked into allowing an attacker posing as a team member through their email to 1) request recovery and 2) complete it to gain access to their data. Always confirm recovery requests "in person" — face-to-face, Skype, etc.

[Deleted User]

Hello again, @Brenty! On all fronts again, I see… How do you to this? :chuffed:

@Ben was certainly right to make this point. I consider myself to be pretty familiar with 1Password and I admit that the awesome amount of power associated with Recovery had eluded me entirely, although it does make perfect sense. That goes to show that familiarity should never be confused with intelligence and I really feel I ought to have realised this earlier! :lol:

As an aside, I might not be alone in having laboured under such a grave misapprehension for so long. Maybe the web app could pop up a sterner warning whenever Recovery privileges are granted to a user or a group? Just a thought… :unamused:

I believe I am good, thanks to your kind help and patience. Can you confirm that the following scenario is OK based on the white paper:

1. Malicious Marcus is granted Recovery powers by stupid admin — let us call him FJ.
2. Marcus now has the ability to access vault keys for other team members, as part of the recovery process. However, no such recovery procedure is started.
3. Stupid admin FJ realises his error, thanks to insightful remarks by AgileBits super-heros — let us call them @Ben and @Brenty.
4. FJ removes Marcus from all groups with Recovery abilities, although not the hidden Recovery group mentioned in our other thread because FJ obviously wants Marcus's account to be recoverable if need be. (Plus, FJ cannot edit groups he cannot access.)
5. Marcus is now unable to access any keys for vaults beyond his own and any vaults shared with him. Furthermore, because no recovery procedure was ever started by Marcus, he has never been sent any keys and the vault keys of other users do not need to be rotated in spite of Marcus's maliciousness.

All good? :dizzy:

[Deleted User]

Thank you, @brenty. My last reply to you appears to have been thrown into the moderation queue for some reason. Maybe the forum is tired of my questions! :silenced:

AGAlumB

@Deleted User: Ha! No, not by a long shot. For whatever reason, it was flagged as spam (many @ mentions? I'm not sure), but it probably didn't help that it turns out you had never verified your account after signing up. We've taken care of that for you behind the scenes here so it will be less likely you'll run into trouble with that in the future. :)

As an aside, I might not be alone in having laboured under such a grave misapprehension for so long. Maybe the web app could pop up a sterner warning whenever Recovery privileges are granted to a user or a group? Just a thought… :unamused:

Hmm. It's something we can consider. But generally when recovery privileges are granted it's because you're giving someone much broader powers: invite team members, create and manage vaults, etc. I'm sure there are exceptions, but I think generally speaking someone you're going to trust with adding a team member should be trusted to be discerning when it comes to recovering one as well.

And as for your example, you're right on. I guess my nightmare scenario would be someone malicious getting access to an admin's account by posing as them for recovery, thereby making it possible for them to pose as other team members and start recovery for them to go through the entire team. Essentially any special powers we grant need to be carefully considered, which is why everyone (part from the Owner) is invited as a "boring-old" team member to start, and additional powers must be explicitly granted. Cheers! :sunglasses:

[Deleted User]

Thank you, @Brenty, for everything — starting with your patience. All is now clear thanks to you, and hopefully a little more secure, too. :sunglasses:

As an aside, I do have a special "Recovery Helpers" group, so to speak, whose only power is Recovery, with no access to other admin features or vault management. :ohnoes:

I find users might be perfectly trustworthy — good computing habits, secure machines, etc. — and yet not rank high enough in the hierarchy of the team for them to be officially blessed with management-level powers. That is admittedly an edge case, but I would vote in favour of retaining the ability to grant users and groups recovery powers only, independently from anything else. Just a thought — and the last one. :wink:

AGAlumB

Thank you, @Brenty, for everything — starting with your patience. All is now clear thanks to you, and hopefully a little more secure, too. :sunglasses:

@Deleted User: You're totally welcome! And let's be honest, I benefitted as well. I clearly needed more practice articulating how this works. So thank you for that! :lol:

As an aside, I do have a special "Recovery Helpers" group, so to speak, whose only power is Recovery, with no access to other admin features or vault management. :ohnoes:
I find users might be perfectly trustworthy — good computing habits, secure machines, etc. — and yet not rank high enough in the hierarchy of the team for them to be officially blessed with management-level powers. That is admittedly an edge case, but I would vote in favour of retaining the ability to grant users and groups recovery powers only, independently from anything else. Just a thought — and the last one. :wink:

I think that's a really reasonable — and cool — solution. It isn't something we go out of our way to recommend because, as evidenced by this conversation, it really depends on you knowing your team and what roles are a good fit for everyone. And it also only works with the Pro plan's custom groups. But yeah, the worst thing would be if the Owner is the only one with recovery powers, and they forget their Master Password. It's good to have not only checks and balances, but also a solid recovery plan, and it sounds like you've got both. Cheers! :sunglasses: