It's kind of half-baked but the core idea works, so I thought it was time to get some external feedback before I continue with the yak shaving!<p>I started this a while ago, basically the problem we had back then was how to store credentials to access the root user of the management account of an AWS Organization. (This is applicable to anything using TOTP though, not just AWS)<p>The username and password would go in the team password manager, but what about MFA?<p>For those not familiar with AWS, this is the most powerful super user you can have there. It's irrelevant to explain how bad it is if this is compromised; but the thing is even a clueless, good faith user can screw up badly if they use it incorrectly.<p>So it's really, really important that it is secure.<p>With other credentials, we had hardware tokens in a safe, or a printed TOTP QR code also in the safe. I think this is a good, high friction process in normal times. But, we were in full pandemic mode back then, and the team was distributed across the country. That was a bit too high friction...<p>Eventually, we decided to use TOTP as second authentication factor. We set it up during a screen sharing session, and 2 or 3 of our team just added the secret to our personal phones.<p>Now, the few of us would know what to do in a break-glass scenario, and clueless good faith users from above, randomly stumbling upon the AWS credentials in the shared password manager, would not be able to use the username and password alone.<p>This is when I came up with the idea for farMFA - what if, instead of each of us having the full TOTP secret - would only have a "share" of it? With enough shares (n out of m), one could then temporarily reconstruct the TOTP secret, get the current time, generate a code, and complete the authentication process.<p>Vault uses this concept[^1] (and in fact, I used their Shamir's Secret Sharing implementation for this) to initiate the "unsealing" process. The master encryption key is split across multiple users: when the server comes up, at least some of those users (the exact number is configurable) must provide their share to reconstruct the key, and allow decrypting the vault in memory. An attacker with access to the physical storage would then be unable to retrieve the decryption key.<p>Here, we do the same with the TOTP secret (the QR code, basically), splitting it across multiple users. When somebody needs access, they ask everyone else to submit their share to a server, which will then generate and return the TOTP code for a limited amount of time.<p>[^1]: <a href="https://developer.hashicorp.com/vault/docs/concepts/seal#shamir-seals" rel="nofollow">https://developer.hashicorp.com/vault/docs/concepts/seal#sha...</a>