Feature Request: "Nuclear codes" aka "two-man rule" option for especially sensitive vault items
We use 1password at our company to protect secrets. It works great. But, some secrets are more sensitive than others. This feature request proposes a strategy to add an extra layer of protection to critical secrets.
Practical example: we have a single "master account" for our cloud tech stack that is placed in a 1password vault with very restricted access. This account was used once upon a time to create the owner accounts for sub-organizations; those accounts, in turn, were used to create accounts with reduced privileges, and so on. Our expectation is that the only reason anyone would need to access the master account is during rare events like tearing down / adding a new division, shutting down access to a compromised admin account, and so forth.
As you can imagine, a compromise of the master account credentials could be catastrophic.
We've considered just taking credentials like this out of 1password entirely and storing them in a physical location, like a bank's safety deposit box. But, this isn't ideal, since in the event of a major breach of an admin account, it could take hours or even days to gain access to the master account.
Our middle-ground suggestion would be the option to mark a vault item as requiring more than 1 user (perhaps from a selected "trusted group" of users) to unlock the item to enable viewing it. This could be thought of as a virtual version of the classic two-man rule where two people people have to turn their keys at the same time to start the nuclear launch sequence :)
One implementation approach might be to mimic the existing "account recovery" process and chain the access requests:
- User 1 requests access to the item
- Other users in the "trusted group" are notified by email of the need to confirm access
- One of the users follows the email link to approve access
- After authenticating successfully, they click "grant access"
- The original requestor is notified of their access
Benefits:
- Requires an attacker to compromise more than one user account in 1password to gain access to secret
- Reuses an existing, proven UX in 1password (account recovery)
- Creates a semantic marker in 1password for the most important secrets; additional measures like more granular access logs and notifications around these special vault items could be implemented later, too.
Other considerations:
- Once this feature is enabled on an item, it would make sense to require the same multi-step approval process to disable/change its settings. Otherwise, an attacker could simply compromise the owner of the vault item and disable this feature prior to accessing it.
- An even more extreme version of this feature would be to require multiple users to authenticate together within a tight time window (more akin to the real 2-man rule where the keys have to be turned at the same time). But, I don't know if that really provides much incremental security over the "chained" approach described above.
Thank you for your time!
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
+1 This seems like a useful feature! Could think of a few things I'd like to have multi-party security on.
0 -
Hey @oratner... this is definitely an intriguing idea! I'm a developer, so my tendency (good or bad) is to start thinking about implementation as soon as an idea comes up. And this is a good one... so I wondered how possible this could be.
Hopefully it goes without saying that security is of the utmost importance when it comes to situations like this, so not only do we want to make sure that we are restricting access to the data which lives on our servers... but we also want to make sure that it is also encrypted in a similarly secure method. So that even if someone who was not supposed to have access to the data were to obtain it... they would still be left with the problem of decrypting it.
The access part of this idea is probably not too terribly difficult to solve... it's the encrypting side of it that I suspect would pose more of a challenge. As this would require that no one person have the keys to decrypt something by themselves. We have a bunch of really smart cryptographers here at 1Password and this sort of multi-key encryption would definitely have to pass through our Chief Defender Against the Dark Arts and be found to not be susceptible to any attacks that might decrease the security of the data. As @Jacob said, we'll have to pass it along to him and the others on the team to see what they think. Fingers crossed there might be a secure way and a future feature!
To follow up with an idea of how you might secure your cloud tech stack, you might try to put all the necessary vault items into a single vault and then restrict access to that vault by removing "View/Edit" permissions from everyone and every group. Leaving only "Manage" access to the vault for whomever you feel should have that responsibility... whether that be a group like Owners or Admins... or even a single individual. Of course this means that a single individual who has Admin privileges in your account could still compromise things, if the attacker knew what they were doing. But this would at least not keep that vault and all of those secrets on anyone's devices. Instead requiring first that the compromised account be given at least some sort of viewing permission before the vault would even appear.
Hope that helps!
0 -
Hi @brettbollman !
Thanks for taking the time to consider our idea! Your suggestion for cutting down View/Edit permissions and isolating into a separate vault makes sense; I'll look into doing that.
I had figured the encryption approach would be the most interesting (read: challenging) aspect of this idea. It's been a few years since my university crypto class, but I don't recall learning about schemes to encrypt a secret with multiple keys that allowed for decryption using a threshold subset of those keys in arbitrary order. Sounds like a cool paper idea if it hasn't already been solved.
I can imagine a hack like encrypting the secret P(N,2) times, where n=# of trusted people, to enable decryption via any two people in any order (i.e.: for n=5, 5!/(5 - 2)! = 20 encrypted versions). But, I imagine that approach this might fall prey to something akin to a "reused key" type of attack if proper safeguards weren't put in place, not to mention it would put a practical cap on the max number of trusted users for secret (which, arguably, would be a good thing anyway!).
Anyway, this is a fun problem to think about as a developer (and as a product manager, it'd be a cool feature to talk up on a landing page ;-) but I'll stop brainstorming for now and cross my fingers you all decide it's worth pursuing :)
0 -
Hi @brettbollman !
(somehow deleted my original comment while trying to fix a typo; oops! will try to retype now)
Thanks for the suggestions around locking down View/Edit permissions on the vault; I'll definitely do that.
I had figured that the encryption side of this idea would be the most interesting (read: challenging) aspect of the proposal. It's been a few years since my university crypto class, but I don't recall learning about schemes to encrypt a secret with multiple keys that allowed for decryption using a subset of those keys in arbitrary order. Sounds like a cool research paper if it hasn't already been solved.
I can imagine a hack like encrypting the secret using each ordered pair of trusted users, i.e.: P(N,2) where N=# of trusted users. So, 5 users = 5!/(5-2)! = 20 encrypted versions. Of course, this might be susceptible to something akin to a reused key attack for all I know. It would definitely put a practical cap on the number of trusted users for a given secret, but that might actually be a good thing!
In any case, this is fun to think about as a developer (and as a product manager, it'd be fun to talk up on a landing page as a differentiator / reason to upgrade to Teams), but I'll stop brainstorming and just cross my fingers you decide it's worth pursuing :)
0 -
That's weird, the old comment came back. Oh well, sorry for the duplication, it won't let me delete now :)
0 -
Probably got caught in the spam filter temporarily. Sorry about that. Thanks again for your thoughts and suggestions. :)
0
