Trying to build a login system where nobody holds the keys, including us

I work at Tide so keep that in mind. I’m posting this because the idea took me a while to get my head around and I think it’s interesting even if you never use anything we make.

In 2023 someone got their hands on one of Microsoft’s token signing keys (look up Storm-0558 if you haven’t heard of it). I don’t think anyone ever fully worked out how. With that one key they could make their own login tokens and they used them to read email at a bunch of organizations, some of them government. The thing is nothing was really “broken” on the checking side. The signatures were valid because they were made with the real key.

Most login systems have a key like that somewhere. Or a table of password hashes, or an admin account that can give anyone any role. We work really hard to protect those, but they’re still sitting there, and whoever gets one gets everything.

What we try to do is not have that key exist in one place at all. It gets created in pieces across a bunch of independent servers and never gets put back together. On the main network there are 20 of them and 14 have to agree before anything is signed. When you log in, each one checks your token’s claims for itself before adding its piece of the signature. So hacking the login server doesn’t get you the key, because the login server never had it. Passwords work in a similar way, so there’s no hash table to steal either.

If you want the basic intuition, look up Shamir’s Secret Sharing. Two points define a line, so you can give out three points and any two of them are enough to work out the line, but one point alone tells you nothing. What we do is a lot more complicated than that but it’s the same basic idea.

The part I like most is admin changes. Adding a user or giving someone a role has to be approved by a group of admins, and the approval is checked by the network. So one admin can’t just quietly give themselves more access, even if they own the server and the database. Nobody has that kind of power over the system, including us.

That’s really the bit that changed how I think about trust. Normally when you sign up for something you’re trusting the company not to misuse the power it has over your account, and you’re also trusting that nobody ever steals that power from them. That’s a lot to take on faith, and after the last few years of breaches I don’t think many people give it easily anymore. But if the power isn’t sitting with any one company, admin or server, there’s a lot less you need to take on faith. You don’t have to believe we’re good people or that our servers are perfectly locked down. You can look at how it works and see that we couldn’t do it even if we wanted to. Taking the authority away is what actually leaves room for people to trust it.

If you want the deeper version, the whitepaper is here: Emergent Authority Whitepaper | Tide | Tide

1 Like

This is a fascinating architectural philosophy, @sashyo. The Storm-0558 incident is the perfect case study for why centralized root keys are effectively “cryptographic single points of failure.”

Moving from simple Shamir’s Secret Sharing (SSS) to what sounds like a production-grade Threshold Cryptography / Multiparty Computation (MPC) engine is an awesome design pattern []. It completely redefines the concept of zero-trust.

My main question when looking at a 14/20 threshold setup like this is state synchronization and latency. In traditional JWT validation, checking a signature is an instantaneous, local CPU operation. With your network, when a user logs in, how do you handle the network overhead of coordinating 14 independent server nodes to generate their partial signatures without causing noticeable authentication lag for the end-user?

Thanks for linking the whitepaper, definitely giving this a deep read!


1 Like

Hey @iamaruloly ! Sorry for the late reply, just saw this.

To clarify a few things: Tide’s unique cryptographic scheme (Ineffable Cryptography) uses a multiparty mechanism when signing a JWT, because that’s the sensitive part. The JWT validation hasnt changed because it’s zero trust. It holds no secrets! The JWT validation is still an instsantaneous, local CPU operation. Also, if you apply the same question to the signing process, Tide still doesnt add any meaningful latency when signing the JWT. Even across the 20 nodes it uses everytime. This effciency is achieved because the “coordination mechanism” is a parallel ( all 20 at once), non-interactive ( no node is dependent on other nodes) and oblivious one. The latency this mechanism costs ends up being the same as using any cloud based authentication (Auth0, Clerk, Cognito, etc)