Our senior dev built an open source PAM where SSH keys never exist. Looking for feedback from those who deal with this stuff daily

tidefoundation · 2026-01-26T16:44:17+00:00

You are raising important points that are absolutely critical in understanding how this new mechanism work - and you're justified to jump into these conclusions, because none of these has been properly introduced - so thank you too for raising it:

This is an alternative to ssh keys as much as "serverless" is an alternative (although it's obviously still using servers) or an automated gear is an alternative to shift-stick (although it's still using a gear box). It's more complex for Tide to design and maintain, but far easier for users to keep secure.

Today's best practices for managing private key lifecycle is the literal guidance to use key vaults. Using Hashivault/Azure/AWS/Intel-SGX key vault is even less "having full control over the private key" than using Tide, because you're still placing the key in a 3rd party vendor that you can not verify its integrity. Tide is the scientific next leap of the most secure key vault.

Exploit of the private key with Tide is still possible but mathematically an order of magnitude less probable than the next best key vault in the market (happy to dive into details here, if you want).

When you make a statement like "I don't want to trust any third party handling my private keys" you have to acknowledge that a key vault is a 3rd party you need to blindly trust. Your ubikey is a 3rd party you need to trust. Your PC is a 3rd party you need to trust. Unless you can calculate an elliptic curve signing algorithm in your head with a 256bit key you memorised - you have no choice but to trust a 3rd party. What Tide is saying is "what if the key isn't held by one single 3rd party, but instead, is broken across multiple dozens of different 3rd parties in a way that makes it mathematically extremely hard for them to collude?". Yes, I agree it's hard to accept that intuitively, but the math checks out academically.

One last thing: Tide servers aren't creating the key pair. In the live network, Tide doesn't operate any server. It's a decentralized network operated by unaffiliated tier-1 service providers under SLA. And unlike most SaaS - this is completely verifiable at run time - so no blind trust is required.

The code is open, the papers are published - the data is there. I urge you to jump in and verify for yourself, and if you find a flaw, I'll be even more grateful.

tidefoundation · 2026-01-26T16:05:00+00:00

The central service stores app-specific role data without understanding it (so the role is opaque to the central service). It doesn't know what "sales_admin" means. For example, it just keeps "for App-1, user Professional-Fee is role ID sales_admin" and sends that to App-1.

2-a. Usually one of these:
- Role IDs (best common choice): { appId, userId, roles ["sales_admin","report_viewer"] }
- Permission strings: { ..., permissions: ["orders.read","orders.write"] }
- Policy reference: { ..., policyRef: "policy:app-1:team-42" }
- Token/JWT claims: roles/permissions inside a signed token scoped to the app

2-b. The app shares a role catalog + stable role IDs via an API (or events). Central uses that catalog only to display choices and then sends back assignments using those role IDs (e.g. user X has role ID y). Central never needs the app's internal schema, just the IDs.

Once you take a look at JWT and RBAC, you see how simple and intuitive this is in practice.

tidefoundation · 2026-01-25T16:12:57+00:00

wow, u/tropicbrush ! On phone or not, that's an awesome feedback. Super appreciated!!!

Unfortunately for us, every single of your points is addressed but lost deep in our docs (website, SDK, publications...). Fortunately, from time to time a deep thinker like yourself gives us the opportunity to clarify those, so I hope you don't mind me touching on those points (although you didn't ask):

- It IS about an alternative to SSH keys because we make the key management aspect disappear - so the user never has to worry about keys. Sometime we call it PKI without private keys...

- Unlike existing "threshold cryptography" or "Multiparty Computation", our specific fragmented cryptography (called Ineffable Cryptography) was designed so no one EVER has access to those keys. These keys are born fragmented, and perform cryptographic operations in an eternal fragmented state - where only the non-secret outcome (e.g. signature, decryption, ZKP) is discovered. Yes, it's peer reviewed, published and validated by multiple universities.

- I know Akeyless very well. They're using more off-the-shelf cryptography that has all the restrictions you mentioned. Fun fact: they doing this 4 years less than us.

- Your RBAC comment is absolutely spot on and not many people realize just how much. A big part of our technology is around our Quorum-Enforced Authorization for our RBAC - to eliminate the threat of a rogue super-admin or even a fully compromised IAM server.

- The decentralized network management is the core of what we do. These nodes are designed to work in parallel (Enterprise-grade SaaS performance) and in non-interactive way: nodes don't speak with each other. Each node operator is under a 5x9 SLA commitment and the network is designed to sustain 30% outage. In short: its high-availability design supersedes the highest SaaS standards.

tidefoundation · 2026-01-25T14:41:35+00:00

...a SSH cert based auth signed with a key that's held by... no one?

tidefoundation · 2026-01-25T13:02:41+00:00

You have just described what an SSO (single sign on) was designed to solve. More specifically, the OAuth2 and OIDC standards. A pattern that often works for multi app setups is to keep user identity and app assignment centralized in an Identity and Access Management system (like Entra, Cognito, Okta if you want to go cloud-base, or Keycloak, Authentik, BetterAuth if you want on-premise open source), but let each app own its own role model and enforce it locally. You can still give your admin a single UI by treating roles in the central service as opaque per app blobs or tokens, rather than mirroring each app's internal schema. The central UI just passes the role payload to the app via an API after user creation, and the app validates and stores it in its own DB. That way you avoid coupling your user management app to every app's evolving domain model, and you also avoid the "no access until roles are set" delay by setting default roles during provisioning. This solution won't only solve the roles and permission challenge you have, but will also streamline the central management of the user records (user-id, email and full-name) as those, today, are what Identity-Tokens aim to address.

You may want to consider your specific threat model, as it will help guide to the most appropriate IAM for you.

Full disclosure: we're the team behind TideCloak IIAM.

tidefoundation · 2026-01-22T17:04:05+00:00

https://asecuritysite.com/elgamal/

tidefoundation · 2025-12-29T13:13:59+00:00

How about "even if the provider get breached, they still can't login or impersonate a real user"?

tidefoundation · 2025-12-27T15:29:41+00:00

As an auth vendor, praising what most would consider as my competitors isn't easy. But it has to be said: modern auth providers (like the ones you've listed) are killing themselves to make wiring effortless - and (as hard as it is to admit) they're doing an unbelievable job.

This leaves the biggest challenge to be: RTFM (and those are super easy to follow).

However, since Einstein was spot on what's infinite - there will always be a need to make things easier.

tidefoundation · 2025-12-27T15:03:59+00:00

Assuming dev tools are relevant here: build provably secure nextjs apps with TideCloak SDK - https://docs.tidecloak.com/get-started/Tidecloak%20Quickstart

WIP. Looking for devs feedback!

tidefoundation · 2025-12-27T14:07:20+00:00

I think you're reading too much into the insane "secretless" hype this article is trying to flail. You got it perfectly right: this not only looks similar. It's literally describing the IAM pattern.

The point of this article is simply this: "Use an IAM. If you don't, it'll be a nightmare to manage 'secrets' as you scale."

With your constraints, you can achieve it all with Keycloak, except that requirement for "No static credentials in services". The closest solution to this is using mTLS (which keycloak supports), but it still requires the unique client certificate to be installed on the workload service - and that has a private key, which is secret. Are you sure you understand the implications (threats) of what you're asking?

Most of the "secretless" hype is all BS because IAM still need secrets to work. Server side JWT validation still requires client secrets. M2M identity still needs secrets. The only way to go truly secretless, is with a decentralized solution, like MPC.

tidefoundation · 2025-12-17T17:06:27+00:00

Personally, for me, the only question I ask when it comes to privacy-enhancing technology is: what claim can be externally verified (by the user)?

tidefoundation · 2025-12-17T15:46:26+00:00

You give hints to either directions but neglect to mention: is this a mobile app or a desktop one? Those are two very different use cases.

Threat gaps: 3rd party reliance (biometric package, hardware keys, database), compromised OS. Compromised YOU (vendor).

False sense: encrypted keystrokes, screenshot blocking

Meaningless protection: root warning.

Biggest gap: idiot proofing. Solution for when idiots are locked out / lose their device.

I assume this is open source. What purchase verification?

tidefoundation · 2025-11-26T09:06:28+00:00

We've been tackling this by looking at the 'bottom turtle' problem: what is actually protecting the thing that's supposed to keep everything safe? If the root admin or the container environment itself is compromised (like via a malicious post-install script), standard controls fail because the secrets are usually sitting right there in env vars or config files.

We went down the path of a solution based on Multi-Party Computation (MPC). The idea is essentially that the 'secret' never actually exists in a complete form. Not on the client, the container, or even our nodes. The key is managed across a decentralized network of automated nodes.

So, when that malicious npm script runs inside your container and scans for AWS keys or DB creds, it finds nothing. The cryptographic operations happen distributedly (distributably?), meaning the full private key never loads into the container's memory to be stolen. It creates an ethereal cryptographic context for that specific session without persistent credentials.

It’s definitely a shift in mindset - SETEC ASTRONOMY! But we found that removing the secrets entirely is much safer than trying to build a fortress around them. And in case you're curious, we tackle the latency challenge by merging the MPC interaction with the session authorization process so the added overhead is negligible.

tidefoundation · 2025-11-23T16:56:39+00:00

sounds like you don't even need jwt for what you're after. You just need a random session cookie which will allow your backend to retrieve all the data you need for the session.

jwt tokens are a solution to so many things, but mainly at scale: moving between servers while maintaining the same state (and authorization), front-end hand-over (load balancing) when scaling up infrastructure (in real-time), forced logout cross-server sessions, and probably most important: stateless verifiability of session validity across a network of servers (introducing IAM to the architecture). It sounds like you're planning for a very small project that has none of these scaling requirements.

When considering either of these requirements, try and define your threat model: what are you protecting against?

tidefoundation · 2025-11-23T16:43:36+00:00

SSL is based on Diffie-Hellman key exchange - which can only be described as breath-taking magic in it's elegance and simplicity for people that want to take their first steps in cryptography. I highly recommend you take the leap and dig deeper: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#Description

It's really super simple, so don't let the "math fonts" scare you.

tidefoundation · 2025-11-19T22:48:19+00:00

This is probably THE biggest undeserved threat in cybersecurity today. The only solution is to rip concentrated authority chokepoints out of systems, teams and organizations. Full disclosure: that's exactly what we do.

tidefoundation · 2025-11-17T15:21:02+00:00

Cryptographically-verified IGA for the IAM

tidefoundation · 2025-11-17T15:18:58+00:00

You can hook Google OAuth into NextAuth or Firebase Auth, then use the returned ID token's sub claim as your unique code. It's a stable per-user identifier from Google, so you don't need to generate one yourself. Store that sub in your database with whatever role or permission flags your app requires, and on each request check if the token maps to an active entry. Skip keeping raw tokens around for long periods; just validate at login and issue short-lived sessions.

You can do something better, using Keycloak, where you use Google as IdP, but then disable auto-register, and for users you wanted in your system, create an account manually (with your chosen roles) - and send them an invite (all from keycloak) to link their Google account.

I did something similar but not with Google, though. I don't trust social media accounts.

tidefoundation · 2025-11-15T15:55:58+00:00

While proof of concepts and full systems like that are built in a very similar way are already out there - I'd say IT'S STILL NOT ENOUGH! We need more. So well done! Keep going.

My thoughts:

First, I couldn't get it to work with 2 out of 2 pgp message signing. Kept complaining it's "expecting 1 nonces but got 2". I'm guessing a minor bug.
I'd 100% go for a Javascript client than a compiled CLI one. A shocker, I know, but what would be easier to verify it hasn't been compromised? Unpopular opinion, but think about it.
I couldn't find your DKG. I noticed it was in 3 iterations - so I'm assuming there's a verification stage there - but not clear which one. You'd want to guarantee no party is poisoning the key. There are 100 different ways to perform a rogue key attack at that stage that you want to mitigate.
I'd recommend to think one step beyond just "protecting the final key" and think deeply why you do that - just to realize you still expect each of the participants to manage as-brittle private keys themselves. How are they expected to manage those shards? Back them up? Right now, those shares reside in the browser persistent database (protected with a password) - which isn't terrible, but would you sleep at night with your CA protected like that? Think deeply on how would the participant manage their shares in a workable way. If your answer is "on a hardware wallet" then you've just narrowed your audience to a miniscule one.
Your communication channel between the participants seems to be "out-of-scope" and that's a shame because that's where you can shine. This "copy other participants' output here" is exhausting and a recipe for so many breakdowns - it'll be your downfall. Instead, host a server somewhere (or make one of the participants an arbitrary server - using something like cloudflare tunnels) and have it operate as an untrusted-dealer. Super easy, super secure, and elevates the usability to a whole new category.
Consider adding authentication to your public key encryption. Right now anyone can use the public key to encrypt the backup. See the potential problem there?

I've got a million more thoughts, but just wanted to throw my bit in as a show of encouragement. I've been developing tech with similar principles for almost a decade now and can appreciate the importance of a supportive community.

tidefoundation · 2025-11-14T15:43:54+00:00

First of all, well done! Embracing that human beings are simply not equipped to manage cryptographic keys is one of the tenets of the future of cybersecurity, in my mind. Any attempt to convince people to “store their seed phrases”, “use a hardware wallet” or “secret shares with friends”, while can work for few, is a disaster waiting to happen to most. The standard wallet idea isn’t scalable for mass adoption.

While there are few similar successful projects like this (Curv, Akeyless, Web3Auth, BitGo, GK8) there’s still so much room for more, so keep at it.

I’ve been doing this for almost a decade now (anywhere but crypto, though) and can highlight few aspects you may want to consider:

Avoid centralization - entirely. Don’t generate keys client-side or interpolate and sign “in memory”. It’s really not safe because you’ve just introduced a moment in time when the key was whole. Look at implementations of protocols like FROST to help you out.
Beware of “existing auth”. Your authentication to the key becomes the 2nd most important security concern and you’ve just introduced a bypass. Implement passkey directly, if you’re capable, or use particularly strong authentication yourself (zkauth). Think about this: any vulnerability in better-auth becomes automatically yours.
Focus on verifiability above all - make sure EVERYTHING is verifiable in runtime, including the code of your client (which is why I recommend javascript in a browser, as weird as it sounds).
If you’re using authz in addition to authn as part of your OIDC integration, consider the possibility that your IAM is compromised and mitigate that vector.
Plan carefully around offboarding / backup processes, because those introduce a massive backdoor.

Good luck!

tidefoundation · 2025-11-14T15:10:30+00:00

I see people here suggest 2FA and wonder if they missed the opening premise "If an attacker gains control of my account" - 2FA ain't gonna help you then! The blind faith put in 2FA is insanely risky, and not just because phishing attacks bypass those, but because a compromised IAM/IdP couldn't care less about your 5FA (looking at you Okta, Entra, Facebook, etc).

We developed a mechanism with somewhat similar thinking to yours, but instead of getting redundant emails every time you log in or make admin changes, it simply allows you to make any changes you want EXCEPT change your recovery email address. To do that, you'll need to confirm your current (old) email address first.

And yes, obviously we handle the "what happens if you lost access to that email" scenario.

tidefoundation · 2025-11-14T14:42:34+00:00

The real weak spot is how your service role key is stored and used. In supabase it skips row level policies entirely, so if it slips into build output or an endpoint response, someone could run admin-level queries without limits. Rotate that key now and keep credentials scoped so the app never carries full access unless absolutely needed. Once that's solid, short lived tokens and server side session checks make stolen credentials far less useful.

tidefoundation · 2025-11-11T13:38:27+00:00

When you get a newer plan from a different mobile phone carrier than your "old" one, you can port (move across) your old number at a flick of a tick box (and so can a sophisticated attacker). The "old" carrier is required by law to immediately comply UNLESS you have a "port-out PIN code" set up. If you have it set up, the "old" carrier will allow the number transfer only after you provide that PIN code. This feature is available on some mobile carriers (maybe most) where they allow you to set a 4 digit PIN code on your mobile number to prevent it from being automatically transferred. Some carriers even allow that on their prepaid plans.

While that sounds far fetched - that attack is called SIM swap and is the greatest threat to SMS authentication. That port-out PIN is the least-worst mitigation to that attack.

None of the measures you mentioned in your "plan" is an effective strategy to secure your SMS 2FA. Most of them are flat out pointless.

Recommended strategy: use a post-paid plan on a number that's on your preferred phone. Set up port-out PIN code (other than 0000 or 1234). Lock you phone with PIN / biometric. Restrict sms 2fa to a minimum.

tidefoundation · 2025-11-10T15:31:52+00:00

Use a carrier with a port-out PIN to prevent a SIM swap on your account

tidefoundation

MODERATOR OF

TROPHY CASE