Account Recovery and Emergency Kit Practices

cjcampbell

I'm posting in part to get a second verification on one detail of account recovery, i.e., can it recover account when the secret key is lost as well as the master password. I believe this is the case, but want to be sure I fully understand the data loss risk.

That said, we've been trying to refine our advice for customers deploying Teams on our recommendation. Our experience is that the average user neglects the guidance to print the emergency kit or they create it and store it insecurely. The chief problem here is that the user is left to do too much thinking.

We would like to develop some guidance for our clients that would remove some of this uncertainty from the onboarding process. My first inclination in this scenario is that the emergency kit may not be necessary for teams that have a sufficiently well-defined recovery process and multiple admins. If this is the case, however, I'd love to see owners given the ability to turn off the default emergency kit instructions (otherwise the uncertainty remains).

The second alternative we've considered (for certain clients) is to instruct users to save the recovery kit as a secure document and share with their manager or team owner. If recovery works the way I expect, this option seems to be redundant. If not, I'd also love to see some customization of recovery kit configuration in this scenario. Namely, I would prefer users not store their master passwords with the recovery kit.

I do find the kit helpful in certain scenarios. For smaller teams and admins of larger teams, it's much more manageable to store the recovery kit in a bank deposit box or other secure location. This procedure is easy to define and easy to follow, so we can work with relatively high confidence that the organization will be prepared to recovery lost accounts without having to jump through hoops.

Would appreciate any thoughts or feedback. I recognize these aren't one-size fits all suggestions, but I do think they add something of value for organizations with less sophisticated IT capabilities.

AGAlumB

I'm posting in part to get a second verification on one detail of account recovery,

@cjcampbell: Great! Thanks for getting in touch! :)

i.e., can it recover account when the secret key is lost as well as the master password. I believe this is the case, but want to be sure I fully understand the data loss risk.

Yes. Any member belonging to the Recovery group (Organizer, Owner, Admin, etc.) can perform recovery for any other member, which allows them to generate a new Secret Key and choose a new Master Password. I don't blame you for asking. It really is that simple. :sunglasses:

That said, we've been trying to refine our advice for customers deploying Teams on our recommendation. Our experience is that the average user neglects the guidance to print the emergency kit or they create it and store it insecurely. The chief problem here is that the user is left to do too much thinking.
We would like to develop some guidance for our clients that would remove some of this uncertainty from the onboarding process. My first inclination in this scenario is that the emergency kit may not be necessary for teams that have a sufficiently well-defined recovery process and multiple admins. If this is the case, however, I'd love to see owners given the ability to turn off the default emergency kit instructions (otherwise the uncertainty remains).

Honestly, the Emergency Kit is not necessary for anyone. It is only needed in instances where the user needs their account credentials and does not have another option. So while it's definitely recommended for all users (and MOST strongly recommended for individual users), if a team has a sufficient contingency plan with members who can perform recovery, it may not be needed at all. So you raise a good point about people storing it insecurely being a liability in that scenario. However, I don't think it's reasonable to assume that most users are in a situation where they belong to a large team with many members capable of recovering their accounts, so our general recommendation — and the way we design 1Password — needs to reflect that.

The second alternative we've considered (for certain clients) is to instruct users to save the recovery kit as a secure document and share with their manager or team owner. If recovery works the way I expect, this option seems to be redundant. If not, I'd also love to see some customization of recovery kit configuration in this scenario. Namely, I would prefer users not store their master passwords with the recovery kit.

For your purposes, I think that (based on careful evaluation of the team strategy of course) you may be able to eschew the Emergency Kit entirely. And provided there are sufficient recovery options, this is by far preferable to giving account credentials to another person for security reasons.

I do find the kit helpful in certain scenarios. For smaller teams and admins of larger teams, it's much more manageable to store the recovery kit in a bank deposit box or other secure location. This procedure is easy to define and easy to follow, so we can work with relatively high confidence that the organization will be prepared to recovery lost accounts without having to jump through hoops.

I agree completely. That's a very good assessment of team scenarios when the Emergency Kit is a good fit.

Would appreciate any thoughts or feedback. I recognize these aren't one-size fits all suggestions, but I do think they add something of value for organizations with less sophisticated IT capabilities.

I think you're right on. I hope you'll appreciate that we can't apply this thinking to 1Password.com as a whole, but it's clear that you've given this a lot of thought (and perhaps trial and error) and have good ideas about what works and what doesn't. Really glad you took the time to bring this up. :)

cjcampbell

Thanks for the feedback! I had reservations about giving the emergency kit to an admin (since compromise would be less apparent, so I'm glad to know that it's not absolutely necessary when the recovery process is a reliable option.

Any chance you might add a feature to the backlog for team owners to tailor the default alerts that are given to new team members. I find that users on these teams are a bit thrown off when our instructions about the emergency kit contradict the 1P guidance.

AGAlumB

Thanks for the feedback! I had reservations about giving the emergency kit to an admin (since compromise would be less apparent, so I'm glad to know that it's not absolutely necessary when the recovery process is a reliable option.

@cjcampbell: Indeed. Account recovery is actually the most reliable option, since a user might do exactly the right thing and print their Emergency Kit, storing it in a secure location...and then forget to print a new one if they change their Master Password or Secret Key. The only scenario where recovery isn't an option is when no one else can perform this function (for example, single Owner with no admins forgets his Master Password).

Any chance you might add a feature to the backlog for team owners to tailor the default alerts that are given to new team members. I find that users on these teams are a bit thrown off when our instructions about the emergency kit contradict the 1P guidance.

Honestly, while it's something we can consider, I don't think we'll do that. I know that sounds contrary to everything else I've said, but as an individual user, the only person you know you can rely on is yourself. Ultimately the account credentials are the user's responsibility. Not recommending they save their Emergency Kit (or telling them not to explicitly) means they are entirely dependent on another team member in an actual emergency, and there's no guarantee there will be someone who can come through for them> Again, it's something we'll continue to evaluate with feedback, but we don't want to encourage people to dig their own graves here either. :blush:

cjcampbell

I do understand, but I would also mention that the current setup is tricky from a governance standpoint. My clients fall almost exclusively under a compliance framework, e.g, HIPAA, where this sort of recovery process should be governed by the organization’s security officers. It’s probably not too likely that the onboarding process for a password manager would attract too much scrutiny from a regulator, but it’s not too far removed from some of the scenarios I’ve witnessed (the process is supposed to be risk driven but auditors will sometimes cling to the most irrelevant inconsistencies).

Thanks for taking it into consideration, and I’ll say I’d even settle for something buried under an advanced/expert config label with an additional warning pop up and occasional reminders to the team owner attached. At the very least, I’d encourage some user research to better understand the balance of risk ... As we add more clients into the 1Password ranks, we will share our observations!

AGAlumB

I do understand, but I would also mention that the current setup is tricky from a governance standpoint. My clients fall almost exclusively under a compliance framework, e.g, HIPAA, where this sort of recovery process should be governed by the organization’s security officers. It’s probably not too likely that the onboarding process for a password manager would attract too much scrutiny from a regulator, but it’s not too far removed from some of the scenarios I’ve witnessed (the process is supposed to be risk driven but auditors will sometimes cling to the most irrelevant inconsistencies).

@cjcampbell: In what sense? 1Password.com is HIPAA compliant, and I'm not seeing where they would be violating confidentiality by simply saving their Emergency Kit during account setup — unless they're doing it on a USB flash drive or something, but I can't say I agree that this would be the fault of 1Password. I think they would need to follow the rules of the organization regardless, and I'm not sure that's something we can enforce. :(

Thanks for taking it into consideration, and I’ll say I’d even settle for something buried under an advanced/expert config label with an additional warning pop up and occasional reminders to the team owner attached. At the very least, I’d encourage some user research to better understand the balance of risk ... As we add more clients into the 1Password ranks, we will share our observations!

That's an interesting idea too. Thanks so much for your thoughts on this, and don't hesitate to follow up if you think of anything else that we might need to consider. :)

cjcampbell

@brenty Thanks again for engaging in conversation. I hope this is helpful perspective (even if a little long-winded). I'm definitely not aiming to beat the issue into the ground.

@cjcampbell: In what sense? 1Password.com is HIPAA compliant, and I'm not seeing where they would be violating confidentiality by simply saving their Emergency Kit during account setup —

In this case, I'm focused more on risk management and governance responsibilities than a direct confidentiality violation. Covered entities and business associates who rely on 1Password, for storing protected health information or passwords related to the PHI, still need to define their own policies and procedures that capture how they integrate the password manager into their relevant business processes. Since we're nudging clients toward password management solutions to deal with a specific set of risks, we emphasize some key points in the relevant policies and procedures. It's most likely to show up in onboarding, offboarding, password management, user account management, and/or business continuity/disaster recovery plans.

The scenario I imagine (and while there's a level of absurdity, I don't think this is grasping at straws) is a business being investigated for a user account management or password-related breach at which point the Office of Civil Rights at HHS would request risk assessment documentation and policies/procedures related to the these processes. The most applicable would be a breach that gets tracked back to stolen password management credentials from a prior break in. Having dealt with auditors in HIPAA and other processes, I have seen them get hung up on inconsistencies like instructing employees to disregard security related prompts in the software. It's a total nitpick and unlikely to result in a penalty, but it can waste a lot of time and is sometimes used to expand the scope of the audit/investigation.

I think I mentioned it before, but I do want to be clear that the regulatory risk associated with the feature is quite low. My main concern is that many non-technical users get quite anxious about any inconsistency in process (and that managing their anxiety helps keep them invested in the process). The more tangible risk of a breach still gives my spidey-sense a tingle too. Given the current prompts, a non-zero number of users won't read the employee handbook or will generate an emergency kit just to be safe. Based on my experience, only a few of these employees will take appropriate measures to protect the information. Given enough time and users, there's going to be a compromise.

Which risk wins depends a lot on the target organization, but I'd say the risk associated with not generating the emergency kit can be effectively eliminated for a lot of teams given the tools that exist. Taking your thoughts into consideration as well, I think it's appropriate to put concerns about the user losing access behind the organization's ability to manage the risk they deem to be most significant. That said, I'd still bury the option in expert settings behind a click-through warning and maybe even limit the option to teams with multiple recovery administrators. :)

AGAlumB

@brenty Thanks again for engaging in conversation. I hope this is helpful perspective (even if a little long-winded). I'm definitely not aiming to beat the issue into the ground.

@cjcampbell: Definitely helpful! I was really curious what you had in mind, so I appreciate your response. :)

Having dealt with auditors in HIPAA and other processes, I have seen them get hung up on inconsistencies like instructing employees to disregard security related prompts in the software. It's a total nitpick and unlikely to result in a penalty, but it can waste a lot of time and is sometimes used to expand the scope of the audit/investigation.

That's a really good point. At the end of the day, it's up to the company to determine policies like this. We can only give recommendations based on general security principles, so if you (or your clients) have restrictions you need to mandate over and above the policies implemented in itself, that's understandable.

I think I mentioned it before, but I do want to be clear that the regulatory risk associated with the feature is quite low. My main concern is that many non-technical users get quite anxious about any inconsistency in process (and that managing their anxiety helps keep them invested in the process).

You're totally right. Sending users conflicting messages is a bad thing. I think we really need to be consistent here, but it's something we'll continue to evaluate with regard to different companies' policies.

Taking your thoughts into consideration as well, I think it's appropriate to put concerns about the user losing access behind the organization's ability to manage the risk they deem to be most significant. That said, I'd still bury the option in expert settings behind a click-through warning and maybe even limit the option to teams with multiple recovery administrators. :)

Haha yeah. Hidden options can bring with them other problems, but I think in this context it's worth consideration. Cheers! :)