Show HN: TideCloak – Decentralized IAM for security and user sovereignty
54 points ·
SaltNHash
·
After 6 years of R&D, our small team is excited to share our project TideCloak - an IAM designed to help developers move fast without worrying about catastrophic breaches or overpowered admins with keys to the kingdom.
Traditional IAMs rely on centralized authority - admins, root certificates, and decryption keys - which create glaring vulnerabilities in a breach. To address this, we’ve integrated Keycloak (Red Hat’s IAM) with a decentralized key architecture powered by our (academically validated) Ineffable Cryptography.
Here’s the idea: keys are split across a decentralized network (our Cybersecurity Fabric) so no one ever holds the full key. Even in a breach or F$%k up, there’s no unchecked authority exposed.
Right now, TideCloak uses the Cybersecurity Fabric as an IdP, meaning users authenticate without their credentials being stored or shared. Essentially, users bring their own authority - without needing to trust anyone else to keep it safe.
Coming soon: - Identity Governance Administration to prevent super admin abuse. - User-sovereign digital assets, where assets are secured with unique decentralized keys to protect against mass breaches.
We’ve just launched a free developer sandbox, and we’d love your feedback: https://github.com/tide-foundation/tidecloak-gettingstarted
It’s still early stages, and your input will help us improve.
Thanks for taking a look - ask us anything!
HumanOstrich ·10 days ago
Update: I found the answer and the research paper[1]. Based on what I've gleaned so far, this looks pretty awesome. It's like.. Horcruxes, but the participants assemble it blindly and instead of getting a soul, you get access to something without revealing the key.
[1]: https://arxiv.org/abs/2309.00915
Show replies
motohagiography ·10 days ago
so shamir secret sharing, which requires users to coordinate to unlock vaults and get tokens, and if one key gets compromised, the attacker still has to solve the coordination problem with a threshold of other key holders. that's within the realm of things we trust today.
there are a few black boxes and flags in the description that would ordinarily get hammered pretty hard by security people who have to make decisions about this stuff, but more charitably:
I'm guessing the fabric is probably a ledger that users subscribe to and that's how it becomes decentralized? imagining how this works, tidecloak adds its fabric as a party to each users (ephemeral?) SSS vault, where the fabric would usually be a centralized dependency, but if the number of SSS parties on the user vault is 3 or greater, your fabric key also requires coordination with another party to participate in unlocking the vault, so it can only participate optionally in an SSS vault decrypt- and probably just for something like a change/recovery operation?
(I'm speculating a bit to draw out some concrete corrections, as the some of those term usages in the description would draw heavy flak in a technical sales or architecture meeting.)
Show replies
laxk ·10 days ago
[1] https://www.w3.org/TR/did-core/
Show replies
e12e ·10 days ago
They're not really being served customized content, are they? All the content is in the react app - so client side - even if not logged in?
I suppose one could argue the authz details are "served" based on login - but the example could really use an example of api/db access unless I'm missing something?
Show replies
PLG88 ·7 days ago