Comment by hn_throwaway_99 | Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

Parent Full thread

hn_throwaway_99

Does anyone know if secret sharing, or the equivalent, is provided by cloud vendors as a way to secure extremely sensitive high level permissions?

For example, most cloud services have the concept of an "owner" account that has full access to everything in a project. Most security advice I've read says that pretty much nobody should have access to the owner account - the credentials for the account should basically be locked in a vault (but that kinda just pushes the issue to "who has the keys to the vault").

Instead, what I'd like to do is share the owner account password into 4 parts, where any 2 are needed to get access to the owner account. That way no single employee can "go rogue" on their own. Obviously I can share the password by myself using something like SSS, but would be nice if I could just designate a group of n IAM accounts, but where a minimum of k are needed to get full owner privileges. The idea is similar to the "2 keys must be entered at the same time to launch the nukes" idea.

Basically, just curious if other folks share their owner account creds that require some minimum consensus before accessing.

I've been working on something similar to what you described[^1], using Shamir secret sharing to split the TOTP secret. Once enough key holders get together, a server generates some TOTP tokens, but only for a limited period of time.

I wanted to use it in an enterprise environment to limit the access to AWS root users in a break-glass scenario. Now I no longer have such need and haven't developed it further, but the core features are there. As usual though with this kind of tools, any security problem becomes a key management problem and it'd need a bit more work to use it in the real world.

[^1]: https://github.com/borgoat/farmfa

Thanks, this actually helped give me a good idea about how I would like to do this now:

1. Generate the password for the owner account, store that in "standard" secrets storage where admins can access it. 2. Also require TOTP MFA for the owner account. Take the seed for the TOTP, and split that into N shares (where N is equal to the number of admins you want to share it out to) requiring K threshold (where K is the minimum number of admins that must come together), and give that out to your admins.

Yes exactly, that's the idea with that tool, this would make the process compatible with most services (I'd hope, that all services that require this level of attention also offer TOTP).

I believe the sensible next step would then be to implement a mobile authenticator app for this protocol, that can scan QR codes, perform the initial "split", send out the shares, and then orchestrate the generation with other players.

The initial step is the weak link: the user could just store that TOTP secret and everything else becomes pointless. It'd be great to have the service itself (e.g. AWS) generate those shares on their end and send them out individually. But then again, a malicious actor with that kind of access to begin with would have a thousand other ways to do some damage.

you do this by securing the 2fa device for the account in a bank safe that offers 2+ person rule for access

Understood, I was just hoping that cloud vendors (or associated tools) would implement the "2+ person rule for access" directly within their interfaces.

Honest question: wouldn’t one person knowing the password and the other owning the 2FA device also achieve the same result?

yes you can also store the 2fa on-prem in a safe that the person with PW access does not have access to. different tradeoffs/risks involved

Reply on news.ycombinator.com