Forem: Tide Foundation

KeyleSSH: A New PAM Concept for IT Admins

Tide Foundation — Thu, 12 Feb 2026 01:28:50 +0000

For greater security and less admin overhead

Infrastructure security is built on a paradox: to protect your assets, you must create a catastrophic single point of vulnerability - a vault, a Certificate Authority, or a database that holds the keys to everything. The US Treasury Department learnt that lesson the hard way when they put their trust in a single vendor last year.

The industry's answer has always been "a safer box": bastion hosts, PAM vaults, rotation policies. But a key stored anywhere is a key exposed somewhere. We call this the key-under-mat problem.

Our senior dev at Tide, Sasha, spent a few weekends trying a new PAM approach that eliminates both the key and the mat. No key left to secure or rotate, also leaves nothing to steal and zero admin overhead.

She built and open sourced the PoC, KeyleSSH, a browser-based SSH console that replaces the centralized vault with a decentralized secrets manager.

The Architecture: Ineffable Cryptography

KeyleSSH utilizes the Tide Cybersecurity Fabric, a network of nodes (ORKs) that operate on secrets without ever seeing them. This is based on a framework we call "Ineffable Cryptography" - A cryptographic scheme where secrets that are never expressed in whole, therefore can never be lost, stolen or misused.
Traditional Multi-Party Computation (MPC), used by advanced vaults to operate on split keys, still momentarily combines the pieces inside a Trusted Execution Environment (TEE). The protocols behind Ineffable Cryptography, however, remain entirely blind from start to end. The key is never reconstructed, not even in a TEE. A signature, decryption or other key action is mathematically constructed directly from the distributed shares performing partial operations.

Instead of a server holding an SSH private key and signing user requests, the signing operation itself is distributed:

Authentication: The user performs Zero-Knowledge authentication via OIDC (via TideCloak IAM), receiving a token bound to their device and session.
Request: KeyleSSH constructs a signing request containing the raw SSH challenge bytes and human-readable metadata.
Consensus: The request is sent to the decentralized Fabric. Nodes independently validate the policy (e.g., "Is User A allowed to access Server B?").
Threshold Signing: If the policy passes, nodes generate partial signatures using Tide's special MPC. These are combined to form a valid Ed25519 signature.

Crucially, the private key is never reassembled. Even if you compromised a node in the fabric, you would find only mathematical noise. To compromise a single key, you would need to compromise a majority of nodes simultaneously.

The underlying protocol has been formally analyzed over 7 years of academic research. Read one of the cryptographic proofs here.

The Implementation: 30 Lines of Code

Proper key management is notoriously difficult to implement. When used as part of a cryptographic protocol, like SSH, it usually requires specialized cryptography teams and complex state management. With KeyleSSH, none of that is necessary.

What makes KeyleSSH interesting is that Sasha built the core proof-of-concept in only few weekends using the TideCloak SDK. The SDK abstracts the complex orchestration of the decentralized network and the key lifecycle management into a standard async interface.

This is the actual code that replaces the entire "secure vault" backend of a traditional PAM:

`client/src/lib/tideSsh.ts`

import { IAMService } from "@tidecloak/js";
import { TideMemory, BaseTideRequest } from "heimdall-tide";

export function createTideSshSigner(): SSHSigner {
  return async (req: SSHSignatureRequest) => {
    const tc = (IAMService as any)._tc;

    // 1. Pack the data (Metadata + SSH Challenge)
    const humanReadable = createHumanReadableInfo(req);
    const draft = TideMemory.CreateFromArray([humanReadable, req.data]);

    // 2. Construct the Request for the Fabric
    const tideRequest = new BaseTideRequest(
      "BasicCustom", // Protocol
      "BasicCustom<1>", // Version
      "Policy:1", // The policy contract to execute
      draft,
      new TideMemory()
    );

    // 3. Attach Authorizer (The user's doken)
    const dokenBytes = new TextEncoder().encode(tc.doken);
    tideRequest.addAuthorizer(TideMemory.CreateFromArray([dokenBytes]));

    // 4. Execute Distributed Signing
    // The SDK handles the communication with the ORK nodes.
    const initialized = await tc.createTideRequest(tideRequest.encode());
    const sigs = await tc.executeSignRequest(initialized, true);

    return sigs[0]; // The valid Ed25519 signature.
  };
}

This snippet achieves something that previously required expensive hardware modules (HSMs) or high-risk software vaults: generating a valid signature without the signing key ever being present in memory.

The Demise of the Rogue Admin

Because the authority over assets now live in the network, away from the PAM and anyone administering it, we can enforce logic that even a root admin cannot bypass. For example, a policy can require M-of-N signatures from other admins before granting access to a production cluster.

Unlike application-layer logic (which can be patched out by a rogue admin), this approach is a constraint enforced by the signing network itself. If the quorum isn't met, the mathematical threshold for the signature is never reached.

Current Limitations & Alpha Status

While the architectural model offers significant advantages over centralized PAMs, KeyleSSH is currently a proof-of-concept.

Browser Security: The client runs in a browser. While we use Subresource Integrity (SRI), a compromised endpoint device (malware on the admin's laptop) remains a threat vector.
Centralization of the Testnet: Currently, the Tide ORK nodes are operated primarily by the Tide test network. We are working toward a fully decentralized mainnet, but today, trust is still placed in the Tide infrastructure providers.
Host Hardening: As with any PAM, this solution solves the authentication problem. It does not replace the need for standard OS-level controls, patching, or network segmentation.

Summary

KeyleSSH demonstrates what's possible beyond the "trusted vault" era. By pushing state and authority to a decentralized fabric, we eliminate the Single Point of Failure that plagues modern infrastructure. It doesn't eliminate every security risk, but it does eliminate the "central trust" blast radius that underpins traditional security stacks.

Links

Source Code: github.com/sashyo/keylessh
Live Demo: demo.keylessh.com
TideCloak SDK: docs.tidecloak.com

Beyond Patching: Mitigating RCE with Architectural Cryptography

Tide Foundation — Mon, 08 Dec 2025 23:21:14 +0000

TL;DR

How to shut down the next "React2Shell" by removing its target, so patching becomes important hygiene, not the last line of defense.

The disclosure of CVE-2025-55182 (React2Shell) - a CVSS 10.0 Remote Code Execution (RCE) vulnerability in React Server Components now being actively exploited and added to the CISA Known Exploited Vulnerabilities catalog - is a wake-up call for developers. With 39% of cloud environments running vulnerable React or Next.js instances, the attack surface is massive.

This vulnerability highlights a fundamental security principle: Your system is only as secure as the most valuable secret it holds.

When an RCE occurs, an attacker gains shell access to the backend server. If that server holds the database credentials, API signing keys, or cloud secrets, the breach instantly escalates from an application exploit to a catastrophic, systemic compromise.

While robust defense-in-depth (like input sanitization and Zero Trust) is mandatory, the new cryptographic paradigm "Ineffable Cryptography" introduces a fundamental shift that allows developers to remove the target assets entirely from the attack surface.

What Is Ineffable Cryptography and How Does It Mitigate React2Shell?

Ineffable Cryptography is a practical application of advanced cryptographic concepts like Threshold Cryptography and secure Multi-Party Computation (sMPC). It fundamentally changes the relationship between your application and its secrets.

1. The Core Principle: Decentralized Key Authority

In traditional systems, a single key (a secret string, file, or token) grants "god-like" authority over data or systems. This key is stored in a single vault, file, or configuration variable on the backend server, making it the Single Point of Compromise (SPoC).

The Ineffable approach eliminates the SPoC by ensuring the full cryptographic key is never assembled or stored in one place.

Fragmentation: A key only exists in multiple, useless pieces (fragments).
Decentralized Network: These fragments are distributed across a decentralized, independently-operated network of nodes.
The Swarm Rule: To perform any action (like signing an API request or decrypting a database field), a mathematically predetermined number of fragments (a swarm) must securely cooperate. The full key is never reconstructed, even during the computation. Nodes remain forever blind to both the key and the eventual result.
Quorum-Governance: Setting the parameters around the swarm-action, like who's permitted to request, on what conditions, etc., can only be done with an explicit approval of a quorum of admins. No single admin can go rogue or risk compromise.

2. The Developer's Benefit: Removing the RCE's Ultimate Goal

Traditional Architecture (Vault on Server)	Ineffable Cryptography Architecture
Attacker Action: Executing a shell command: `cat /etc/secrets/db_password.env`	Attacker Action: Executing a shell command: `cat /etc/secrets/db_password.env`
Result: The database password is exfiltrated. The attacker has full, persistent access to the most valuable asset, leading to data theft.	Result: The file only contains a cryptographic stub or token. The secret password is not present on the server. The attacker's ultimate goal is defeated.

The compromised server is reduced to a "dumb terminal" with no authority. It can only request usage of a key, but the key's authority rests outside the server, distributed and secured by mathematics.

Key Takeaway for All Developers

Every developer, regardless of their role, must understand that vulnerabilities like React2Shell expose the entire application's security surface. You should assume that other React2Shell-class weaknesses already exist or will inevitably be introduced somewhere in your software supply chain. A determined attacker will discover them before you do, which is precisely why the architectural layer of your security is just as important as the code layer.

Immediate Fix: Patching the insecure deserialization in the React environment is the first and non-negotiable step.
Long-Term Defense: Evaluate where your most critical secrets reside. If a successful RCE on any backend server grants an attacker access to your master keys, you have a Single Point of Compromise.

New cryptographic models, like the Ineffable approach, offer an evolution in security architecture. Shifting from defending the bastion that holds the key (Zero Trust) to eliminating the existence of the key within any container entirely. By removing the target asset, the most severe consequences of RCE become structurally impossible.

Frequently Asked Questions

What are the affected frameworks?

CVE-2025-55182 affects the React Flight protocol's deserialization logic in:

React 19.x (react-server, react-server-dom-webpack, react-server-dom-parcel)
Next.js (tracked separately as CVE-2025-66478, now merged)
React Router
Waku
Parcel RSC (@parcel/rsc)
Vite RSC (@vitejs/plugin-rsc)

Where can I find additional reading on this?

For a deeper dive into Ineffable Cryptography and the concepts that underpin it, see Reimagining Cybersecurity for Developers.

How to future-proof your web app's password authentication

Tide Foundation — Mon, 29 Sep 2025 06:14:34 +0000

TL;DR

Declare:

const { login } = useTideCloak();

Add this:

<p><button onClick={login}>Login</button></p>

That's it. No password storage, no hashing logic.

Some context

Traditional authentication knows dangerously too much. Its sole job is to determine whether users are who they claim to be, and nothing more. Yet today's systems must both know how to challenge users (password/biometric) and decide if they're valid. Whether you hash and salt passwords locally or use OAuth via a provider like Okta or Facebook, someone still holds secrets. When that someone is compromised, because you trusted them implicitly, you absorb the fallout.

It feels unavoidable. But what if authentication could verify a user without sending or storing secrets anywhere, and without trusting any single party to act as the authority? That's what we're building with TideCloak.

The problem with current approaches

Password hashes are targets. Modern GPU clusters can test billions of combinations per second; offline attacks thrive on stolen hashes.
Social login shifts trust. You're now betting on the provider's security posture. Credentials (or their derivatives) still exist somewhere and can be attacked offline.

How it works

Instead of storing credentials, TideCloak converts each credential into a zero-knowledge proof of a challenge that only the rightful holder can solve, then shards that proof across a network of independent nodes. No single node holds enough to reconstruct any meaningful proof, or to act as the sole authority to validate it. During login, the user engages the network to obtain a short-lived proof. The user's credential becomes effectively ineffable - beyond the ability to be expressed anywhere, by anyone.

INEFFABLE /ɪnˈɛfəbəl/ (adj) - too great to be expressed.

Sequence (at a glance):

The user clicks Login, launching a login screen with a secret session bound to the browser.
The user enters their Username and Password, performing a zero-knowledge authentication using Tide's PRISM protocol, against the network.
A correctly entered credentials will manifest a cryptographic proof from the network.
Using that proof, TideCloak sends your app an OAuth2 Access Token (JWT) bound to the secret browser session.

Unique properties and benefits:

Best of both worlds: Familiar, frictionless UX, but passkey level security.
User privacy and identity ownership: Each user receives a deterministic, app-scoped, anonymized identity (untraceable and unlinkable across apps). Their master credentials are trusted to no one.
Nothing to steal: no password database, no hashes, no secrets at rest - Rendering offline attacks (e.g. Rainbow) infeasible.
Provable integrity: network-level and browser-level verification ensure tamper resistance and trust.
Any MITM tampering causes authentication to fail.
Resilient against token hijacking. The JWT is unusable outside its originating browser.

And the implementation looks like this

Create a React app using Vite

npm create vite@latest tidecloak-react -- --template react-ts
cd tidecloak-react
npm install @tidecloak/react

Get TideCloak running
Run a local test instance with Docker:

sudo docker run --name tidecloakdev \
  -d \
  -v .:/opt/keycloak/data/h2 \
  -p 8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=change-me-now \
  tideorg/tidecloak-dev:latest

Tip: Ports 8080 (server) and 5173 (Vite) must be free.

Activate your TideCloak instance
Tide offers a free developer license for up to 100 users.

Open: http://localhost:8080/admin/master/console/#/myrealm/identity-providers/tide/tide/settings
Sign in (Username: admin, Password: change-me-now, unless changed). You'll land on: myrealm realm → Identity Providers → tide IdP → Settings screen.
Click Manage License → Request License.
Complete the checkout with a contact email.

Within a few seconds, your TideCloak host should be licensed and activated.

Export your TideCloak adapter

Go to Clients → mytest
Set Valid redirect URIs to http://localhost:5173/*
Set Web origins to http://localhost:5173
In Clients menu → mytest client ID → Action dropdown → Download adaptor configs option (keep it as keycloak-oidc-keycloak-json format)
Download as tidecloak.json in your project root

Edit src/main.tsx
Add imports:

import { TideCloakContextProvider, useTideCloak, Authenticated, Unauthenticated } from '@tidecloak/react'
import tidecloakConfig from "../tidecloak.json"

Pre-authentication view:

function Welcome() {
  const { login } = useTideCloak();
  return (
    <div>
      <h1>Hello!</h1>
      <p>Please authenticate yourself!</p>
      <p><button onClick={login}>Login</button></p>
    </div>
  );
}

Post-authentication view:

function LoggedIn() {
  const { logout } = useTideCloak();
  return (
    <div>
      <p>You're signed in!</p>
      <button onClick={logout}>Logout</button>
    </div>
  );
}

Mount the app:

createRoot(document.getElementById('root')!).render(
<StrictMode>
  <TideCloakContextProvider config={tidecloakConfig}>
    <Authenticated>
      <LoggedIn />
    </Authenticated>
    <Unauthenticated>
      <Welcome />
    </Unauthenticated>
  </TideCloakContextProvider>
</StrictMode>,
)

Build and run

npm install
npm run dev

Technical properties
TideCloak uses ineffable cryptography where authentication requires collaboration from multiple nodes, and no single node - or any subset below a threshold - can reconstruct credentials or proofs. This is a novel form of secure multi-party computation, validated through published research with RMIT and Deakin universities.

Key properties:

Threshold: authentication succeeds if any 14 of 20 nodes respond.
Resilience: compromising up to 14 nodes reveals nothing.
Unlinkability: each service sees users as unique, unlinkable identifiers (app-scoped).
Performance: on par with, or better than, major cloud IdPs; browser-bound proofs add negligible overhead.

Threat model and limitations
Protects against:

Database breaches revealing credentials/hashes
Insider access to user password material
Token replay in MITM scenarios (browser-bound, DPoP-style proof)
OAuth/IdP provider compromise leaking user credentials

Doesn't protect against:

Keyloggers/malware on user devices
Very weak passwords
Majority network compromise above threshold (≥14/20)

Current limitations:

Internet connectivity required for authentication
Alpha stage - not recommended for production yet

Integration simplicity

The SDK handles the cryptography. Your app calls useTideCloak() and receives a session token. Standard JWT verification works normally.
For existing systems, run traditional auth and zero-knowledge auth on TideCloak in parallel during migration, moving users over as they log in.

Open questions we're working on

We're in alpha and looking for feedback on:

Developer experience
Clarity of the approach
Bugs and feature requests

TideCloak's code is open source - we welcome security reviews and integration feedback.

Dive into the code

One-Click Demo: https://codespace.new/tide-foundation/tidecloak-playground?quickstart=1
Example React project: https://github.com/tide-foundation/tidecloak-gettingstarted
SDK: https://docs.tidecloak.com/
Join the dev community: https://discord.gg/XBMd9ny2q5

We're building this because credentials shouldn't be honeypots, individuals should own their identities, and organizations shouldn't have to carry the liability of securing secrets.

⚠️ Currently Alpha release: not for production use yet. Free developer license (up to 100 users). See Terms.

The God Mode Vulnerability That Should Kill "Trust Microsoft"

Tide Foundation — Fri, 19 Sep 2025 07:46:34 +0000

How One Token Could Have Compromised Every Microsoft Entra ID Tenant on Earth, And Why It’s Time for Authorityless Security

Recently, security researcher Dirk-Jan Mollema disclosed CVE-2025–55241, a vulnerability so catastrophic that it reads like fiction: a single token, obtained from any test tenant, could have granted complete administrative control over every Microsoft Entra ID (Azure AD) tenant in the world. Every. Single. One.

Let that sink in. Dirk-jan uncovered a path where a lab account was all it took to open the doors to every Microsoft cloud customer, from Fortune 500 corporations to the smallest startups.

This isn’t just another vulnerability. It’s another smoking gun that proves our entire approach to cybersecurity is fundamentally broken.

Another God Mode Vulnerability in a Long Line of “Never Should Have Happened” Breaches

The short version for non-technical readers:

An attacker could have become anyone in any Microsoft cloud tenant, accessed anything, and done it all completely undetected with what appeared to be legitimate access that bypassed all security controls. Think of it as finding a master key that opens every door in every building in the world, while also making you invisible to all security cameras.

The technical details:

Microsoft’s backend uses something called “Actor tokens” for service-to-service communication. Due to a critical validation flaw, these tokens could be used across tenant boundaries, granting attackers the ability to read all user data, group memberships, application permissions, even BitLocker keys, completely undetected. When ready to strike, they could create new Global Admin accounts or take over existing identities. Read the full technical breakdown here.

The vulnerability existed because Microsoft’s architecture requires services to have god-like powers to function. They built a system where ultimate authority had to be trusted to someone, and that trust became the vulnerability.

“If We Can’t Trust Microsoft, Who Can We Trust?”

For decades, enterprises have justified their security decisions with a simple question: “If we can’t trust Microsoft, who can we trust?” It’s been the ultimate defense when things go wrong: at least you chose the industry standard.

This vulnerability, along with countless others across the industry, demolishes that logic. Microsoft joins a growing list of “trusted” vendors that suffered catastrophic breaches: Okta’s exposure of all customer support system users, Cisco’s hidden backdoor account exploited in attacks, BeyondTrust’s remote support SaaS compromise, and severe zero-trust flaws in Check Point, Zscaler, and Netskope. Each had the resources, expertise, and certifications. Each failed catastrophically. It's inevitable.

What should really concern you is the invisibility of these flaws. Behind all the security promises and compliance badges, customers had no way of knowing these Actor tokens existed or carried such sweeping powers. You can’t audit what you can’t see, and you can’t secure what you must blindly trust.

The uncomfortable reality is that this is just the vulnerability that was discovered and disclosed responsibly. How many similar flaws are lurking in these vast codebases? How many have already been found by nation-state actors who are quietly exploiting them? When you have systems this complex, with this much centralized authority, vulnerabilities aren’t anomalies. They’re mathematical certainties.

The Ultimate Supply Chain Attack Vector

Large platforms like Microsoft aren’t just targets, they’re supply chain force multipliers. Compromise Microsoft, and you compromise everyone. This vulnerability proved that definitively.

Consider the exponential nature of the attack path discovered: starting from a single compromised tenant, an attacker could jump to every tenant that had guest users, then to every tenant those tenants had connections to. Within minutes, the majority of all Entra ID tenants worldwide could have been mapped and compromised.

Microsoft’s own tenant would likely be one of the first compromised (since Microsoft consultants are guests in countless customer tenants), and from there, every major service provider would be one step away. The entire global business infrastructure, falling like dominoes.

This isn’t a bug. It’s the natural consequence of building systems where ultimate authority must be blindly trusted to the system, and those that administer it.

Why “Authority” Is the Real Vulnerability

First, let’s define what we mean by “authority” in the digital world: it’s the power to grant access, approve actions, or enforce rules within a system. It’s what lets someone or something open the door to sensitive data, change configurations, or allow operations to run. Think of it as the master key to your digital kingdom.

The root cause of this Microsoft vulnerability wasn’t poor coding or lack of testing. It also isn’t correct to say that it’s the need to trust Microsoft. It’s more accurately what we’re trusting Microsoft with — Authority.

As long as someone or something holds it, it can be exploited. Today’s systems are built with someone, somewhere, having the ability to do anything. Maybe it’s an administrator, maybe it’s the vendor, maybe it’s a service account, maybe it’s a sub-system, but that ultimate power exists. And it doesn’t need to. Modern cryptographic techniques have made it possible to build systems where no single entity needs or has complete authority, where authority itself is distributed across multiple independent parties who must collaborate to act.

Traditional security, even “Zero Trust” security, doesn’t eliminate authority. It just moves it around. You stop trusting the network perimeter, but now you must blindly trust your Identity Provider. You implement defense in depth, but at the bottom of that depth sits an all-powerful system that, if compromised, renders every other defense meaningless.

The Actor token vulnerability perfectly illustrates this. It doesn’t matter how many security policies you had, how much you spent on monitoring, or how well-trained your security team was. When the Identity Provider itself is compromised at the most fundamental level, all of that becomes theater.

The Path to Authorityless Security

We need systems where inevitable breaches don’t have catastrophic consequences. We need architectures where authority doesn’t exist in any single place that can be compromised.

Imagine a world where:

No single entity, not even the platform vendor, can access your sensitive data
No administrator, no matter how privileged, can override the system without oversight
No supply chain compromise can grant universal access
No vulnerability, no matter how critical, can provide god-mode to attackers

This isn’t just better for security, it’s for a better ecosystem. Platform vendors can demonstrate they’re beyond reproach. Businesses can verify their security rather than hope for it. Users can trust systems because they don’t have to. Mistakes will be made, breaches will continue, but platforms will be cyber-immune to the consequences.

The technology to eliminate centralized authority already exists. Forward-thinking vendors are adopting it because they recognize the core architectural flaw, don’t want the liability, want to build fast and innovate without losing sleep over breaches, want to simplify compliance, and want customers to trust them because they no longer have to.

Consider how this alternative approach works: authority over user identities, administrative actions, and business data is distributed in the form a key who’s pieces live across a decentralized network. No single node, organization, or administrator ever holds complete power. When someone needs access to data:

Their identity is verified through distributed authentication where no single node knows their credentials
Authorization requires cryptographic consensus from multiple independent servers
Cryptographic keys needed to decrypt data or sign access tokens never exist in any one place, only their cryptographic actions manifest through the collaboration of multiple independent nodes
Even if an attacker compromises the IAM or multiple nodes holding key fragments, they cannot forge access or decrypt data

The crucial difference: there is no Actor token. There is no god mode. There is no single point of authority that, if compromised, hands over the kingdom.

In such a distributed system, the keys that could elevate privileges or forge tokens remain out of anyone’s reach. So even with a vulnerability similar to Microsoft’s, attackers still couldn’t access customer data, impersonate users, or grant themselves permissions. Mathematical guarantees ensure that authority remains distributed, even in the face of compromise.

The Uncomfortable Questions We Must Ask

Next week, another critical vulnerability will be discovered. Another emergency patch will be rushed out. Another post-mortem will be written. But the fundamental problem will remain: we’re trusting single entities with absolute authority over our most critical systems.

Consider the numbers: despite over $300 billion spent on cybersecurity annually, breaches caused over $10 trillion in damage last year. Things are only getting worse. This isn’t a failure of execution, it’s a failure of architecture.

How many undiscovered Actor token-equivalent vulnerabilities exist right now? How many have been found by adversaries who are silently exploiting them? How long can we pretend that “trust Microsoft” or “trust Google” or “trust any single vendor” is an acceptable security strategy?

The answer is clear: we can’t. Not anymore.

The Future Is Authorityless

The Actor token vulnerability isn’t just another security incident. It’s more proof that our entire approach to security is fundamentally flawed. As long as ultimate authority exists in any single place, that place will be compromised.

The future belongs to systems where authority doesn’t exist in any single place. Where cryptographic proofs replace blind trust. Where mathematical guarantees supersede vendor promises. Where the inevitable breach doesn’t mean inevitable catastrophe.

This isn’t about replacing one vendor with another. It’s about eliminating the need for vendors to hold any authority at all, replacing it with distributed, verifiable, mathematically-guaranteed security.

Microsoft has fixed this particular vulnerability. But the architecture that made it possible, the existence of centralized, god-like authority, remains. And it will remain until we collectively decide that trusting any single entity with everything is no longer acceptable.

The question isn’t whether another Actor token-level vulnerability exists. It’s when it will be discovered, and by whom.

Isn’t it time we stopped gambling with that question?

The authorityless architecture described in this piece is not theoretical. Advances in distributed cryptography now make it practical, economical, and verifiable at scale. At Tide Foundation, our peer reviewed research in ineffable cryptography and the development of platforms like TideCloak show how identity and access can be managed without trusting ultimate authority to any vendor, administrator, or insider. The goal is not for customers to “trust Tide,” but to remove the need for trust in any single entity at all.

Learn more at tide.org.

Future proofing your platform

Tide Foundation — Tue, 29 Jul 2025 04:28:14 +0000

Getting Started

So, you want to build the most secure digital platforms on the planet, without the burden of worrying about security, and simultaneously grant your users sovereignty over their identities? Great!

This developer guide will take you through the minimal steps to build your own Single-Page React application, secured with TideCloak - all in under 6 minutes.

TideCloak gives you a plug and play tool that incorporates all the concepts and technology discussed in this series. It allows you to manage your web users' roles and permissions - It's an adaptation of Red Hat's open-source Keycloak, one of the most robust, powerful and feature-rich Identity and Access Management system. But best of all it's secured by Tide's Cybersecurity Fabric so no-one holds the keys to the kingdom.

Prerequisites

Before starting, make sure you have:

Docker installed and running on your machine
NPM installed
Internet connectivity

For the purpose of this guide, we assume to run on a Debian linux host (either under Windows WSL or not).

1. Getting TideCloak up and running

Start a TideCloak-Dev docker container that already includes all the basic configuration and settings to get you going. To get it, open your Docker/WSL/Linux terminal and run the following command:

sudo docker run \
  -d \
  -v .:/opt/keycloak/data/h2 \
  -p 8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=password \
  tideorg/tidecloak-dev:latest

This will take a minute or two, and when it's done, you'll be able to go to TideCloak's console at: http://localhost:8080

2. Activate your TideCloak license

To get your TideCloak host to tap into Tide's Cybersecurity Fabric, you'll need to activate your license. Tide offers free developer license for up to 100 users. To do that, you'll need to:

Access your TideCloak administration console at http://localhost:8080/admin/master/console/#/myrealm/identity-providers/tide/tide/settings
Log in using your admin credentials (Username: admin, Password: password, if you haven't changed it) (You should be automatically navigated to: myrealm realm → Identity Providers → tide IdP → Settings screen)
Click on the Manage License button next to License
Click on the blue Request License button
Go through the checkout process by providing a contact email

Within few seconds, you'll get your TideCloak host licenced and activated!

3. Create your React JS project

Note: You can find deep dives on the provider props, hook return values, TypeScript types, and more in the TideCloak React SDK docs.

a. Create a React app using Vite:
Run the following commands to create a new React app using Vite:

npm create vite@latest tidecloak-react -- --template react-ts
cd tidecloak-react
npm install @tidecloak/react

b. Export your TideCloak adapter:
Export your specific TideCloak settings and hardcode it in your project:

Go to your Clients menu → mytest client ID
Update Valid redirect URIs to http://localhost:5173/*
Update Web origins to http://localhost:5173
In your Clients menu → mytest client ID → Action dropdown → Download adaptor configs option (keep it as keycloak-oidc-keycloak-json format)
Download or copy the details of that config and paste it in your project's root folder under tidecloak.json.

c. Update main.tsx via nano src/main.tsx
Make the following changes:

 import { StrictMode } from 'react'
 import { createRoot } from 'react-dom/client'
 import './index.css'
- import App from './App.tsx'
+ import {
+   TideCloakContextProvider,
+   useTideCloak,
+   Authenticated,
+   Unauthenticated
+ } from '@tidecloak/react'
+ import tidecloakConfig from '../tidecloak.json'
+
+ function UserInfo() {
+   const { logout, getValueFromIdToken, hasRealmRole } = useTideCloak()
+   const isAllowedToViewProfile = () =>
+     hasRealmRole('default-roles-myrealm') ? 'Yes' : 'No'
+
+   return (
+     &lt;div&gt;
+       &lt;p&gt;Signed in as &lt;b&gt;{getValueFromIdToken('preferred_username') ?? '…'}&lt;/b&gt;&lt;/p&gt;
+       &lt;p&gt;Has Default Roles? &lt;b&gt;{isAllowedToViewProfile()}&lt;/b&gt;&lt;/p&gt;
+       &lt;button onClick={logout}&gt;Logout&lt;/button&gt;
+     &lt;/div&gt;
+   )
+ }
+
+ function Welcome() {
+   const { login } = useTideCloak()
+   return (
+     &lt;div&gt;
+       &lt;h1&gt;Hello!&lt;/h1&gt;
+       &lt;p&gt;Please authenticate yourself!&lt;/p&gt;
+       &lt;p&gt;&lt;button onClick={login}&gt;Login&lt;/button&gt;&lt;/p&gt;
+     &lt;/div&gt;
+   )
+ }
+
 createRoot(document.getElementById('root')!).render(
+   &lt;StrictMode&gt;
+     &lt;TideCloakContextProvider config={tidecloakConfig}&gt;
+       &lt;Authenticated&gt;
+         &lt;UserInfo /&gt;
+       &lt;/Authenticated&gt;
+       &lt;Unauthenticated&gt;
+         &lt;Welcome /&gt;
+       &lt;/Unauthenticated&gt;
+     &lt;/TideCloakContextProvider&gt;
-     &lt;App /&gt;
+   &lt;/StrictMode&gt;,
 )

So it looks like this:

import { StrictMode } from 'react'
import { createRoot } from 'react-dom/client'
import './index.css'
import { TideCloakContextProvider, useTideCloak, Authenticated, Unauthenticated } from '@tidecloak/react'
import tidecloakConfig from "../tidecloak.json"

function UserInfo() {
  const { logout, getValueFromIdToken, hasRealmRole } = useTideCloak();
  const IsAllowedToViewProfile = () => (hasRealmRole("default-roles-myrealm") ? "Yes" : "No");

  return (
    <div>
      <p>Signed in as <b>{getValueFromIdToken("preferred_username") ?? '…'}</b></p>
      <p>Has Default Roles? <b>{IsAllowedToViewProfile()}</b></p>
      <button onClick={logout}>Logout</button>
    </div>
  );
}

function Welcome() {
  const { login } = useTideCloak();
  return (
    <div>
      <h1>Hello!</h1>
      <p>Please authenticate yourself!</p>
      <p><button onClick={login}>Login</button></p>
    </div>
  );
}

createRoot(document.getElementById('root')!).render(
  <StrictMode>
    <TideCloakContextProvider config={tidecloakConfig}>
      <Authenticated>
        <UserInfo/>
      </Authenticated>
      <Unauthenticated>
        <Welcome/>
      </Unauthenticated>
    </TideCloakContextProvider>
  </StrictMode>,
)

4. Build your NPM environment

Download and install all the dependencies for this project:

npm install

5. Run your project

Build and run your project:

npm run dev

All done!

6. Play!

Go to http://localhost:5173/ You should see a "Hello!" message.
Click on the Login button
Click on Create an account
Provide a new username, password, recovery email It will now show you that you're "Signed in" and it will show you your anonymous Tide username for this app.

Project recap

Let's review what just happened and what you've just accomplished:

You have programmed, compiled, built and deployed, from the ground-up, a fully-functional ReactJS Single-Page-Application (SPA).
Web users can now sign up and sign in to your SPA, being served customized content to authenticated and unauthenticated users and based on their predefined roles.
Your web users' roles and permissions are managed locally on your very own self-hosted instance of TideCloak - one of the most robust, powerful and feature-rich Identity and Access Management system which you have downloaded, installed, configured and deployed locally.
Your web users enjoy fully-secured Tide accounts, with their identity and access-credentials sitting outside of anyone's reach.
Your TideCloak instance is secured by the global Tide Cybersecurity Fabric that you have activated and licensed.

What next?

There's two additional layers of protection you can configure through TideCloak:

Identity Governance: Establish workflow processes ensuring that no compromised administrator can cause damage.
User walletization: Ability to lock user data with unique user keys secured by Tide's Cybersecurity Fabric - so ownership and privacy can be guaranteed. For early access to these features Sign up for our Alpha Program

Authors

This 5‑part series outlining the worry‑free future of cybersecurity for platform developers is an adaptation of Tide Foundation Co‑Founders Michael Loewy and Yuval Hertzog's keynote at ACM SIGCOMM 2024.

Michael Loewy — Co‑Founder of Tide Foundation and advisor to the Children's Medical Research Institute.
Yuval Hertzog — Co‑Founder of Tide Foundation and one of the inventors of VoIP.

I got 99 problems, but a breach ain’t one

Tide Foundation — Tue, 29 Jul 2025 04:11:55 +0000

Ineffable Cryptography: The science behind a new era of cybersecurity

The future of security – now

So far in this series, we’ve explored why today’s cybersecurity models are flawed. We’ve discussed how centralized authority is the Achilles’ heel of modern systems and how decentralizing authority, inspired by swarm intelligence, can protect against catastrophic breaches. But how do we make this revolutionary idea work in practice?

Enter Ineffable Cryptography – the breakthrough that makes decentralized authority not just possible but practical, economical, scalable and performant. Think of it as the secret sauce that allows us to decouple authority from individuals, systems, and even organizations, while maintaining airtight security. It’s not just a theoretical model; it’s backed by solid mathematics and years of research, validated by experts from RMIT University, Deakin University, the University of Wollongong and others.

But don’t worry, we won’t dive into complex formulas. I’ll explain the concept in a way developers can appreciate – because, at its heart, Ineffable Cryptography unlocks a reality where security is seamlessly integrated into the development process, ensuring breaches are no longer a nightmare scenario. And best of all, it’s just an API call away.

The problem with traditional cryptography

First, let’s revisit how traditional cryptography works. At its core, cryptography relies on keys to secure data – whether you’re encrypting sensitive information or signing off on important transactions. These keys are the backbone of security.

Here’s the problem: those keys have to exist somewhere, and someone always has access to them. Even in the most secure systems, keys are often stored in vaults or managed by IAM platforms. If an attacker gains access to those keys, it’s game over. Despite protections like MFA and advanced monitoring, centralized authority remains the single point attackers target.

Enter Ineffable Cryptography: the key no one will ever hold

Now imagine a world where no one holds the keys – not the admins, not the system itself, and not even the developers who built it. That’s the future made possible by Ineffable Cryptography.

The core idea is deceptively simple: instead of a single entity controlling a cryptographic key, the key is manifested in fragments across a decentralized network of nodes. Each node stores only a piece; no node can reconstruct the full key on its own. When the system needs to decrypt data, authorize permission or sign a transaction, these nodes collaborate. They never share their fragments; each performs a partial computation and returns a meaningless puzzle piece. Only when enough pieces combine does a meaningful result emerge – the key is everywhere and nowhere at once.

How does it work?

Here are the five components that make Ineffable Cryptography so powerful:

Decentralization – Key fragments are distributed across independent nodes controlled by different organizations. A breach of one node doesn’t expose the key. The nodes never communicate with each other.
Threshold Cryptography – Only a subset of nodes (the threshold) must participate for any operation, guaranteeing continuity during outages without sacrificing security.
Zero‑Knowledge Proofs – Nodes prove their partial results are valid without revealing secret information, preventing malicious behavior or man‑in‑the‑middle attacks.
Multi‑Party Computation (MPC) – Nodes work together like a single key vault, performing complex operations while keeping fragments isolated.
Edge Cryptography – “Encrypted at rest” and “in transit” extends to the edge device; decrypted data only ever materializes on the legitimate user’s device.

Together, these create a security model where authority never sits in one place. Developers can now lock sensitive data, identities and permissions with keys no one will ever hold – keys that can’t be stolen, lost or misused.

Why this changes everything for developers

Ineffable Cryptography is a game‑changer because it lifts security without lifting your headcount:

Rogue admins? No problem. No single person – insider or attacker – can assemble the key.
Breaches are contained. Compromising a key becomes improbable, and even then only a single record is exposed.
Continuous verification. Two‑Way Zero Trust means systems continually prove their own integrity before acting, giving developers mathematical assurance that results only materialize when security is intact.

It’s not just about keeping hackers out; it’s about building systems that can survive a highest‑privilege breach without catastrophic damage.

Real‑world application: securing the future of your platform

Imagine you’re developing a platform handling sensitive medical data. Traditionally, you’d encrypt records, rely on a key vault, and use IAM. One misconfigured permission – boom, mass breach.

With Ineffable Cryptography, each record is encrypted by a different key fragmented across a global node network. Even if your infrastructure is breached, attackers must compromise multiple nodes on multiple continents just to unlock a single record. Critical‑infrastructure firms, IAM platforms, universities, password managers, algo‑trading systems and software‑supply‑chain tools are already adopting this model.

The endgame: trustless, secure and scalable

Ineffable Cryptography finally delivers on the promise of Zero Trust, going further by removing centralized authority entirely. No single point of failure. Even in a worst‑case scenario, your platform stays secure.

The Tide is turning

In this series, we dismantled cybersecurity’s Achilles’ heel – **authority * – and introduced a decentralized fabric that grows stronger with scale. Picture a world where individuals bring their own authority, share medical records securely, or track family members without risking privacy. Resistance is inevitable, just as with the cloud, but decentralizing authority is where security is heading.

In Part 5, we'll bring everything together by walking through a real-world implementation, showing you exactly how to turn these concepts into actionable steps. Get ready to see how theory becomes execution, and how this approach can transform your platform's security.

The revolution has begun. Now it’s your turn to be part of it.

Authors

Michael Loewy — Co‑Founder of Tide Foundation and advisor to the Children's Medical Research Institute.
Yuval Hertzog — Co‑Founder of Tide Foundation and one of the inventors of VoIP.

How nature holds the key to cybersecurity’s future

Tide Foundation — Tue, 29 Jul 2025 03:49:32 +0000

Nature's secret to achieving more while risking less — and how you can use it

Lessons from nature

Ants! Precisely what came to your mind when you thought of cybersecurity — right alongside firewalls and Identity and Access Management (IAM) systems, right? Probably not! But consider this unlikely source of inspiration for a moment. These tiny creatures may not seem like experts, but they hold the answer to one of the biggest challenges we face: managing authority.

Individually, ants are simple creatures without much intelligence. They don't have grand strategies or master plans in their tiny brains. Each ant just does its job — gather food, defend the colony, build tunnels. No single ant holds the key to the colony's success, not even the queen, yet, as a collective, they achieve remarkable feats: complex underground networks, food supply chains, and even farming fungi.

This decentralized approach, known as swarm intelligence, allows the colony to thrive without relying on any one ant to keep it running. If one ant fails, it doesn't bring down the whole operation. The colony survives because no single point of failure exists to cripple it.

The problem with centralized authority

Shifting back to cybersecurity. Today's security models, especially Zero Trust, still concentrate authority in single points — admin accounts, IAM systems, root certificates. These are the keys to the kingdom. Once an attacker breaches any of these points, it's game over for your platform.

But what if we could apply swarm intelligence to cybersecurity? Imagine a system where no one holds the keys and authority is spread across a network. No single point holds enough power to take down the entire system. Visualize a key vault that manages the keys you want to protect — and now imagine that vault broken into pieces across a network such that even if several pieces are compromised, the entire key, and therefore the system remain completely secure.

Think of it like trying to launch a tactical missile that requires multiple different keys, each held by different people in different locations. Even if one key gets stolen, the missile stays locked because you still need the other keys.

But if all those key holders still answered to the same authority, wouldn't this just be an overly complicated system with only a slight security boost? Exactly. If the distributed network was still controlled by a single IT team, it wouldn't solve the problem. That's why it's crucial that swarm intelligence operates in a truly decentralized way, spread across multiple independent organizations, so no one controls the network. Think of it like combining the strength of all independent ant colonies.

This is the concept of Cyber‑Herd Immunity — a cybersecurity model inspired by nature but built for the digital world.

The Cyber‑Herd Immunity concept

We're all painfully familiar with herd immunity in a medical sense — thanks COVID! When enough people in a population are immune to a virus, the virus can't spread easily — protecting the entire population including those who aren't immune. The same principle can apply to cybersecurity. Instead of relying on a single system or authority to defend against attacks, we create a decentralized network of systems that protect each other.

The more participants in the network, the stronger the overall defense becomes.

In today's security architectures, we trust centralized systems with too much authority. Once an attacker gains control of that authority, it's like introducing a virus into a body with no immune system. The damage is immediate and widespread.

But in a Cyber‑Herd Immunity model, the authority needed to grant access and unlock sensitive data isn't held by any single entity. It's distributed across a decentralized network of nodes, much like ants distribute tasks across the colony. This decentralization protects the system, even if one part is compromised.

In a decentralized security system, each node (like an ant) has limited authority — incomplete authority. No one node has enough information to unlock sensitive data or grant access on its own. For any operation to be authorized, multiple nodes must collaborate to verify and action the request.

Trustless authority: the key to the future

This brings us back to the core issue we identified in Part 2: authority. In traditional security setups, authority is concentrated in a few places — for example: admins, IAM systems, root certificates, even plain‑text configuration files. But with a decentralized, trustless network, we remove the need to place blind trust in any one system or person.

Let's say you're working on a platform storing sensitive medical data. Normally, you'd trust your IAM system to manage permissions, encryption, and authentication. But what happens if that IAM system is compromised? All the data is at risk.

In a decentralized network, the authority to grant access to that medical data isn't held by a single IAM system. Instead, it's distributed across multiple nodes. Even if one part of the system is breached, the attacker can't access the data without compromising the network. This decentralization doesn't just improve security — it eliminates the authority problem.

No one holds too much power. No one has the “keys to the kingdom.” Even if an attacker breaches several layers of defense, they still won't have enough authority to cause damage.

How this works in practice: decentralized key vaults

Now, let's put this concept into practice with decentralized key vaults. Today, key vaults are centralized treasure chests storing encryption keys, credentials, and certificates. But these vaults are also high‑value targets. If an attacker breaches your key vault, they've essentially hit the jackpot.

But what if instead of one centralized vault, we had a network of vaults, each holding a fragment of the key? No single vault contains the full key, so even if one vault is breached, the key remains secure. And because this network is decentralized, it becomes nearly impossible to compromise the entire system.

Interacting with a decentralized key vault would still feel exactly like any key vault — where you'd treat it as the store of keys, authenticate to it and request it to perform cryptographic operations on the stored keys on your behalf, like decrypt a sensitive record for a particular patient — with one significant difference: you'd have a verifiable guarantee no one will ever hold the complete key at any point, so you can rest assured no breach can occur.

In this decentralized model, each key is generated in fragments distributed across independent nodes. When a request is made to access data, these nodes work together, each performing a small part of the operation. No node ever holds the full key, and no single actor can misuse it. This is trustless authority in action — security that doesn't rely on trusting any single person, system, or vendor.

A new era of collaboration: building the network

Here's where it gets exciting: this decentralized model doesn't just protect your platform — it protects everyone. By joining a network of decentralized nodes, you contribute to the security of the entire ecosystem. It's like being part of a collective immune system that grows stronger with every antigen. The more nodes in the network, the harder it becomes for attackers to breach any single entity.

This isn't just a theoretical concept — it's the future of cybersecurity. A collective of organizations collaborating to protect each other, without the need for mutual trust, decentralizing authority, and turning catastrophic breaches into relics of the past.

By spreading authority across a decentralized fabric, we create a system where no one holds enough power to cause real damage, and everyone — from startups to global tech companies — can tap into the collective security benefits of the network.

In Part 4, we'll dive into the technology that makes this possible: Ineffable Cryptography. We'll break down how decentralized authority works at scale and how this mathematical breakthrough can protect your systems in ways that traditional cybersecurity measures never could. Get ready to explore the fulfillment of true Zero Trust, where everything sensitive is locked with keys no‑one will ever hold — keys no‑one can steal, lose or misuse.

Authors

Michael Loewy — Co‑Founder of Tide Foundation and advisor to the Children's Medical Research Institute.
Yuval Hertzog — Co‑Founder of Tide Foundation and one of the inventors of VoIP.

Ghost in the Network

Tide Foundation — Wed, 04 Jun 2025 03:20:06 +0000

A car engine is only supposed to start with the right key. Yet, as every heist movie shows, pry off the steering column, twist a couple of wires, and the car is yours! The rule that only the key can bring a machine to life turns out to be optional.

Corporate networks operate on the same wishful thinking. Firewalls, cloud apps, and databases are meant to stay locked until a user shows the right credentials, but attackers slip in through overlooked bugs, compromised vendors, or sloppy settings – just to name a few. The login screen feels like a steel vault door. In practice, it's drywall.

Breaches are now a daily headline. One day it's a payroll platform, the next a hospital system. The details change, but not the script. A target system already holds the power it needs to function, so once an intruder finds an unintended path to the controls, they can "start the engine". Unlike a car thief who can only work one dashboard at a time, a hacker can hot-wire a thousand organizations, simultaneously. A single coding slip can – and does – trigger catastrophe.

We keep piling hurdles on real users, like one-time codes, CAPTCHA riddles, fancy passkeys – while the software beneath never truly needs the user's key. It's an architectural flaw we paper over with an ever-growing constellation of security tools. Even with all these tools at our disposal, IBM's 2024 Cost of a Data Breach report pegs the average breach at $4.88 million, a 10 percent jump in a single year.

The time has come to fundamentally rethink this approach. What if we could build systems where the user truly is the missing key?

Imagine a car whose engine could only work with its specific driver present. The driver themselves becomes a missing puzzle piece required for this particular engine to start. Without the driver, this car is just an expensive hunk of steel that not even the manufacturer can operate. Hot-wiring the car would be futile because only the driver can complete the circuit.

Recent advances in zero-knowledge cryptography make this vision achievable for digital systems. We can now treat a user like that missing puzzle piece – one that forever sits outside the system itself. When the real user shows up, the missing piece powers only the slice of data they're entitled to and vanishes when they leave. Beyond that interaction, the email platform, CRM, or AI assistant remains a harmless pile of ones and zeros.

This approach flips the entire threat model. An attacker must first become the user, and even then, the damage stops at that single account. Administrators can't impersonate customers, malware can't rummage through decrypted records, and compliance shifts from promises to mathematical certainty.

Security teams will still patch bugs and monitor logs, but that work becomes maintenance rather than crisis response. Software vendors that embrace this "user-as-key" architecture will become significantly harder targets, and insurers, regulators, and customers will take notice.
The best safety upgrades seem obvious in hindsight. Platforms that require the rightful user’s presence to function will not only shed breach anxiety and liability; they cultivate the kind of trust that turns customers into advocates.

Soon, any service that leaves sensitive data accessible without an authorized user present will seem as outdated as a car without seatbelts.

Another security patch. Another missed opportunity.

Tide Foundation — Tue, 20 May 2025 06:17:44 +0000

If a system (whether it’s a firewall, SaaS app, or database) is only supposed to work once someone has proven they’re entitled to access it (in technical terms: authenticated and authorized), why are they built today with the power to operate before that critical step?

Most systems today are built with this inherent contradiction. It means the system itself has the authority to make decisions about access without needing to verify who is asking, leaving it exposed when that authority is tricked or bypassed. This isn’t a small oversight - it’s a fundamental design flaw.

Fortinet’s latest zero-day vulnerability (CVE-2024–55591) is a fresh reminder of this problem. When a product has god-like access to the sensitive data or abilities it holds, without itself needing external permission, a single exploit can give attackers that level of access. This isn’t a problem that can be fixed by just “patching faster.” It requires a fundamental rethink of how these systems handle authority to begin with.

The problem we keep bandaging over

Every year, we see the same kinds of vulnerabilities hit the headlines. Last November, researchers discovered a new flaw in FortiOS/FortiProxy that allowed attackers to slip straight into the management GUI without presenting a single credential. The patch landed in January 2025 — after the damage was already done. Just this month, another vulnerability (CVE-2025–22252) was found that allowed a particular legitimate mode to skip authentication altogether and log in as an admin.

These aren’t isolated incidents, and it’s not limited to Fortinet.

A history of band-aids

While each entry point or exploit is different, they all take advantage of the same fundamental flaw: once you’re inside the box, you’ve got everything you need to cause damage.

Feel free to skip the boring stuff, but here’s a sample of Fortinet’s history of these “login-optional” bugs:

2024–21762 — SSL-VPN out-of-bounds write lets attackers run code pre-auth
2023–27997 (“XORtigate”) — Heap overflow, again pre-auth on SSL-VPN
2022–40684 — Bypass the admin API, create your own super-admin
2020–12812 — Change username case to dodge FortiToken 2FA
2018–13379 — Path-traversal that leaks raw VPN session files and passwords

Shooting ourselves in the foot

This design approach breaks two fundamental security principles we claim to live by:

Zero Trust: “No asset is implicitly trusted” (NIST SP 800–207)
Least Privilege: Every component should get only the power it absolutely needs

Yet, in practice, we keep building systems with total, unverified power because “that’s how it’s always worked.”

A better model

Instead of designing systems as all-knowing, all-powerful gatekeepers that poorly dispense the explicit access they have over sensitive data, what if the systems themselves lacked that god-like access entirely? What if only through the act of a user successfully authenticating could the system gain the authority to access sensitive data or operations?

It’s like a circuit that only completes when a user logs in. Without that signal, the system can store data, but it can’t act on it. Once the user session is gone, so too is the system’s ability to operate. If the code inside the system is tricked or compromised, the authority over sensitive data is nowhere to be found.

This act of “Decoupling authority” keeps an indispensable piece outside the blast-radius, and only lends it when the user authentically connects.

Moving from “access control” to “authority control”

A way forward

The next patch will come, and another critical vulnerability will follow. To break the cycle, we need to change the way these systems are built, so they literally cannot grant themselves access until someone authenticates. Shift from “access control” to “authority control.” If we do that, there’s nothing stopping us from moving fast because the inevitable breach leaves nothing for an attacker to find.

Original post - here>

Reimagining Cybersecurity for Developers

Tide Foundation — Mon, 03 Feb 2025 07:25:02 +0000

Because you shouldn't have to be a security expert—and let's face it, the “experts” aren’t stopping breaches anyway.

It’s 2025, and breaches still dominate the headlines. Despite an endless array of security tools —and billions spent on security—we’re stuck in perpetual whack-a-mole, forever patching yesterday’s vulnerabilities and bracing for the one we missed.

In this post, we accept the inevitability of the breach and explore a new security model—one that ensures the authority allowing unchecked access to sensitive data or operations remains out of anyone’s hands. Yours included! If you’re the hands-on type, check out the GitHub.

1. The Fundamental Problem: A Single Authority Over Everything

Nearly every platform places absolute authority over secrets, credentials, and user data in a singular centralized system. Sure, we encrypt, hash, or vault them. But from a hacker’s perspective, there’s still just one “god-mode” repository waiting to be plundered.

Single-Point-of-Failure: If an attacker grabs the one set of master credentials—or subverts the singular authority controlling them—everything is compromised.
Privilege Reliance: Even if only a handful of admins have top-level access, each single member essentially holds the keys to the kingdom.

So long as one authority has the final say over user data and credentials, we’re playing breach roulette. We may harden the perimeter, but the jackpot for attackers remains tantalizingly large.

2. The Kryptonite We Won’t Let Go Of

The singular-authority model is cybersecurity’s “kryptonite.” By concentrating the power to unlock data in one place, we’re essentially handing attackers a key to the treasure chest.

Credential Vaults Are Still Centralized: Even the best vault solutions maintain a single authority over keys.
Complex Tool Stacks: Every additional security layer can introduce new vulnerabilities or friction for developers. Their highly trusted nature has been used to expose us.
Under One Roof: When user data and the means to decrypt it coexist in the same environment or with the same people, a breach can unravel everything.

We keep reinforcing walls around this Kryptonite, instead of questioning why we’re holding it in the first place.

3. How Nature Points the Way

Swarm Intelligence, found in various systems in nature, demonstrates a model where no single entity wields absolute authority—and that makes entire systems remarkably resilient.

Distributed Responsibility: In ant colonies or immune systems, the “knowledge” and “power” are spread out, making it nearly impossible to topple the entire system at once.
Local Defenses: Threats spark localized responses. No single bottleneck can bring everything down.
Organic Scalability: These natural structures can grow to massive sizes without creating critical single points of vulnerability or failure.

When authority is decentralized—split across multiple participants—no single compromise can imperil the whole. It’s a blueprint for security that’s fundamentally different from the fortress-and-moat approach.

4. “Got 99 Problems, But a Breach Ain’t One”

Our work at Tide Foundation is translating these ideas into a working model for distributed trust that makes developers’ lives easier:

Decentralized Key Generation and operations: Credentials (or encryption keys) are generated and stored in “shards” across multiple independent nodes. Nodes perform key actions as a swarm—no one node ever “knows” the entire key.
No Single Authority: Even if few nodes are compromised, it doesn’t hold all the credentials, and it doesn’t have unilateral power.
Developer-Friendly Integration: By providing straightforward APIs and libraries, developers offload the heavy cryptographic lifting without sacrificing user experience.

Cutting-edge cryptographic methods (like Threshold Signatures and Multi-Party-Computation) let us ditch the single-authority approach. Instead, each piece of the puzzle is worthless by itself, drastically reducing the incentive and feasibility of a mass breach—enabling developers to build rapidly, and fearlessly.

Final thoughts

It may sounds like a radical shift in thinking, but so was the concept of the—now ubiquitous—cloud computing. Besides, what have we got to lose other than liability?

Check out the multi-part series for the full deep dive, and how-to guide when you’re ready to check how all this works under the hood.

Breaches might be inevitable, but the damage doesn’t have to be.

It’s cybersecurity’s kryptonite: Why are you still holding it?

Tide Foundation — Thu, 12 Dec 2024 05:48:23 +0000

Decoupling authority, so a breach leaves nothing for hackers to find.

The real culprit: authority

In Part 1, we explored how trust isn’t the core issue in cybersecurity — it’s authority and the way we’re resigned to trusting someone or something with it.

Authority, in the digital world, is the power to grant access, approve actions, or enforce rules within a system. It’s what lets someone — or something — open the door to sensitive data, change configurations, or allow an operation to run. Whether it’s an admin with elevated privileges, an IAM system managing permissions, or a cryptographic key that decrypts sensitive data, authority is the ultimate gatekeeper.

Even in systems with comprehensive Zero Trust architectures, we still rely on centralized points of authority, making them prime targets for hackers. If you’re a developer, you’ve likely heard the saying, “A breach isn’t a matter of if, but when.” It could be from something as minor as a misconfigured setting in your cloud infrastructure, a compromised component in your software stack, a phishing attack on an administrator, or a sophisticated zero day vulnerability exploited by state actors — Just to name a few.

The losing game of whack-a-mole that is cybersecurity, means that as long as authority exists somewhere in the system, when it’s exposed, it can bring down even the most secure platform.

“Respect my authoritah!”

As platform developers, you probably don’t wake up worrying about authority. But authority is at the heart of many of the security challenges we face today, and we’re doing a terrible job of managing it.

To understand it, consider this famous myth of the Middle Ages: Chastity belts! Knights heading off to the Crusades didn’t trust their wives to stay faithful, so, these contraptions gave them the guarantee that by holding its key, they’re wielding the ultimate authority. No trust needed!

Fast forward to today: you pull up to a Michelin-star restaurant in your brand-new Ferrari. You apprehensively hand your keys to the valet, thinking what you’d do with that car if the situation was reversed. But thanks to valet protection mode, you’ve throttled the speed and range, stripping away their authority to do anything more than park your car — no joyrides today!

In both cases, authority defines the level of trust required. The knight didn’t need to trust anyone because he held the key. You don’t need to trust the valet once their ability to misuse your car is removed. By stripping away authority, you also remove the risk.

Now let’s jump to a more common scenario: picking up prescription meds. You get a prescription from your doctor (an authorization), and the pharmacist checks it and your ID before handing over the medication (authentication). But who really holds the power here? It’s not the doctor — it’s the pharmacist. They have the key to the medicine cabinet, and if someone else — say, their delinquent 16-year-old kid — gets that key, they become the king of the cabinet (and probably the most popular kid in school). It doesn’t matter what the doctor says; that kid now has the real, explicit authority.

Implied vs. Explicit authority

This distinction between implied authority (the doctor’s prescription) and explicit authority (the person holding the keys) is crucial to understanding why cybersecurity often fails. In modern systems, we assume that those in charge of issuing credentials, managing permissions, or maintaining admin privileges are the ultimate authority, but those are merely agents of implied authority. Something down the line with the explicit authority will need to render judgement after checking those permissions to either honor it or not. Let’s say you’ve got an Identity and Access Management (IAM) system like Microsoft Entra or Okta. Great! You’ve implemented role-based access control (RBAC), multi-factor authentication (MFA), and anomaly detection. But at the end of the day, the IAM still holds god-like power over the system. A misstep by an admin, a compromised credential, or a malicious insider will render all your security measures useless.

In reality, explicit authority — the power to open a file or present sensitive content — is often scattered across the system, hidden in plain sight, waiting helplessly for a hacker (or insider) to exploit the implicit authority providing the directives.

In today’s systems, authority always sits somewhere, on something, with someone controlling it. This is where the real threat lies.

I specifically used an example with a 16-year-old kid in my pharmacist analogy earlier to take you to my next point. In 2021, some of the biggest, most secure and well-resourced technology companies in the world were rocked by devastating cyber breaches. Losing some of their most valuable IP to a ransomware gang led by just such a 16-year-old living with his mom. He didn’t use fancy technology or advanced hacking skills. Instead, he went straight for the sources of authority. He simply bought access credentials from employees that willingly handed it over. All that was needed to steal the crown jewels was the access rights of a sufficiently privileged employee — and it was game over for cybersecurity.

This threat of authority abuse is a fundamental flaw that undermines every digital platform, no matter how secure it appears.

The fatal flaw of authority in Zero Trust today

Zero Trust aims to mitigate risk with the mantra, “Never trust, always verify.” But let’s be honest, our best implementation of this approach is more like “Never trust anyone or anything (except if it’s us or our things).” The problem? We still blindly trust the systems responsible for upholding Zero Trust principles, the IAM system that manages access, or the root certificates that authorize users — these elements hold immense power. Once compromised, all bets are off.

It’s like handing your car to a valet with valet protection mode on, feeling secure — until the valet’s buddy at Mercedes tech support disables it remotely and goes full Ferris Bueller on your car. If that trust is misplaced, it doesn’t matter how strong your security measures are — all unravels once authority is compromised.

We’ve essentially concentrated trust into the very systems that are supposed to be trustless. If breaches are ‘a matter of when, not if,’ why doesn’t that apply to the core systems we now trust to protect us? The answer is probably because there were just no other alternatives. Until now.

Ensuring security isn’t your problem

Let’s visualize the worry-free future you need. You’re a developer, not a security analyst. You should develop tech, build platforms, and deliver features. You shouldn’t have to worry about rogue admins or compromised IAMs. You shouldn’t lose sleep over the possibility that a dodgy line of code or a phishing email could see you featured in TechCrunch for all the wrong reasons.

Even if your platform gets breached, no one should be able to access critical data because no one — not your IAM system, not your vendors, not even you — should hold the ultimate authority to unlock it. Attackers might break through every layer of the Zero Trust stack, but it won’t matter because there’s no single point of failure.

This is the utopia we’re after: a world where developers focus on building without the burden of overhanded DevSecOps and technical debt, and without constantly worrying about how secure every single system is. A world where compliance with regulations like GDPR shifts from a box-ticking exercise into a built-in feature of the architecture. And it starts with decoupling authority from the systems and people who currently wield it.

Evolution needs a leap: beyond physical security

Right now, we treat digital security like it’s just an extension of physical security — a blueprint naturally evolving over the past 300,000 years. We build walls (firewalls), install surveillance (monitoring systems), and place guards (IAMs). But here’s the thing — digital systems aren’t bound by the same constraints as physical ones. In the physical world, someone has to hold the keys. In the digital world, they don’t.

The solution to our authority problem isn’t to shift trust around or to build better IAM systems. It’s to rethink how we handle authority entirely. We need a system where no single person or entity has the power to abuse authority because no one ever fully holds it.

Decoupling authority: a glimpse into the future

So, where do we put this authority once we’ve decoupled it from systems and admins? How do we remove the need to blindly trust anyone or anything?

This is where things get exciting. In Part 3, we’ll dive into a concept inspired by nature itself: Swarm Intelligence. Think of ants. Individually they’re basic creatures performing menial jobs. Squash any one and it poses no threat to the colony. But as a colony, they achieve incredible feats. Applying this same concept by decentralizing authority can provide a new model for cybersecurity.

Next, we’ll explore how a network of organizations can protect each other, much like a colony of ants or a swarm of bees. Get ready for the future of security — where authority is out of everyone’s reach.

Original op-ed published here.

Authors:

This 5-part series outlining the worry-free future of cybersecurity for platform developers is an adaptation of Tide Foundation Co-Founders Michael Loewy and Yuval Hertzog’s keynote at ACM SIGCOMM 2024

Michael Loewy is a Co-Founder of Tide Foundation and serves on the advisory board of the Children’s Medical Research Institute.

Yuval Hertzog is a Co-Founder of Tide Foundation and one of the inventors of VoIP.

Reimagining cybersecurity for developers

Tide Foundation — Tue, 19 Nov 2024 04:24:27 +0000

TL;DR:

Despite advances like “The Zero Trust Model”, cybersecurity is still fundamentally broken, as repeatedly proven by the increasing breaches in the largest, most secured companies in the world. This series unveils an entirely different approach, made possible by a breakthrough in cryptography, that allows developers, like you, to stop worrying about the next vulnerability by locking systems with keys no-one will ever hold—Keys that are impervious to theft, loss, or misuse. This series demonstrates how the introduction of herd-immunity principles to cybersecurity removes today's inescapable need to blindly trust people, brands and processes. This new approach not only promises to redefine cybersecurity, but empowers you to innovate without fear of the inevitable breach. Try it here.

Every developer’s nightmare

You want to build something new, create awesome digital experiences, not to spend your nights worrying about security breaches. Yet here you are, staring at your screen, wondering if that last rushed feature commit opened the floodgates to a data breach. Remember when a single sketchy update nearly broke half the internet? Nobody wants to be that developer.

In today’s fast-paced world, security isn’t someone else’s problem. It’s a target painted directly on you. Cross-site scripting, SQL injections, session hijacking… Every line of code is a potential entry point for hackers, and every decision could lead to disaster. And it doesn’t even have to be your code – but a vulnerable 3rd party package you use!

Zero Trust: a false sense of security?

The Zero Trust model is hailed as the savior of modern cybersecurity. If you’ve spent any time in security meetings or reading up on best practices, you’ve heard of it. It operates on the principle of “Never trust, always verify,” promising to secure platforms by treating everything interacting with your system as a potential threat. On paper, it’s brilliant—the default response to any access request is to grant "zero trust." Then, with appropriate and ongoing validation, the model allows for least-privilege access—giving users and systems only the permissions they need to perform their tasks. Think of it like installing a card reader on every door in your office, from the boardroom to the bathroom, not just the entrance.

Yet, if Zero Trust is the answer, why are we still seeing massive breaches? Despite over $300 billion poured into cybersecurity, breaches caused over $10 trillion in damage last year. Clearly, something isn’t working.

Here’s the kicker: Zero Trust solutions, in their current form, don’t eliminate the need for trust, they just shift it around. Sure, you’re not implicitly trusting the devices or identities interacting with your platform anymore, but now you’re putting blind faith in the very systems that manage that trust—your Identity & Access Management (IAM) system, your antivirus, your monitoring tools—and the people that administer them. It’s like locking every door in your house but leaving all the keys with a minimum-wage guard.

You’ve verified access and enforced least privilege—great! But what happens when the system responsible for issuing these permissions is compromised? Who verifies them? Right now, no one.

Who’s watching the watchers?

The naming of “Zero Trust” is rooted in the base assumption that anything connecting with your platform is afforded no trust, by default. Unfortunately, it’s been obnoxiously slapped onto the packaging of most major cybersecurity products promising “zero” trust, but in reality, we blindly trust those systems enforcing it, with god-like powers. Whether it’s your IAM system, end-point security, or anomaly detection tools, they’re treated as infallible. But what if they’re compromised?

Have you ever checked if your antivirus is doing more harm than good? Can you even verify if the systems you rely on haven’t already been breached? No matter how sophisticated, no system is foolproof—When these particular systems fall, the entire house of cards collapses.

Attackers know this, and they’re going after the systems we depend on—our supply chains, our tools, even the very security measures we’ve put in place to stop them. The result? Breaches are causing damage on an unprecedented scale.

The trust problem isn’t what you think

There are many ways to maximize trust—like improving communications, proving follow-through, and demonstrating accountability—however, even at its top levels, trust is still a form of blind faith. Being such an intangible construct, trust isn’t some parameter you can fine-tune, install or fabricate. Therefore, to remove the need for trust altogether, we must focus on what we’re trusting—authority. A breach of trust becomes problematic only when authority is exploited or abused. In other words: if we remove all authority from something, it no longer requires any trust. It is then guaranteed to be completely safe.

Authority is what gives the power to make important decisions, like granting access to data. Hackers don’t need to break through every layer of security—they just need to compromise the authority that controls it. Whether it’s a rogue admin, a misconfigured server, or a hacked vendor, once authority is abused, your platform is left vulnerable.

Authority is the Achilles’ heel of cybersecurity.

The Zero Trust model aims to remove the need for trust, but today it still relies on systems that wield unchecked authority. Trust in these systems is required because we can’t independently verify what’s happening behind the scenes. The IAM, identifying a user as a super-admin, is hopefully doing so correctly all the time, but how could you know?

But what if we could remove that authority entirely? What if no single person, system, or entity was trusted with enough power to compromise your platform?

Enter Two-Way Zero Trust

Let me introduce you to a new concept: Two-Way Zero Trust. Imagine a world where you don’t just verify everything interacting with your system, but where the system itself is continuously verified—by you and others interacting with it. In this model, no single entity holds unchecked authority. Instead, authority is decoupled from any one person or system and distributed.

Think of it as upgrading Zero Trust’s mantra of “Never trust, always verify” and applying it to everything, including the system itself. Imagine every time your IAM granted a user admin privilege to your platform, you had an instant guarantee it was issued correctly. It’s like building a security fortress where even the guards are under constant verification. And the best part? Even if someone breaches the system, they can’t access sensitive data because the authority to unlock it lives outside the system entirely.

Whether you’re a startup founder or a market leading platform, implementing Two-Way Zero Trust means you can finally sleep at night without worrying about being the weak link in a security chain. Even in the worst-case scenario, your platform stays protected because no one holds the “keys to the kingdom” —shielding you from potential legal liabilities and preserving customer trust. You could rest assured that encrypted data can only be decrypted to correctly-verified users or that write-permission can only be given to those approved of it. For some, this could mean avoiding the kind of catastrophic breach that may spell the end of the company.

Where do we go from here?

So, what’s next? We’ve identified the real problem: authority. Now, the challenge is figuring out how to remove it from the systems and people managing it. It’s not about abstract trust—it’s about ensuring that no one holds enough power to cause catastrophic damage, even if they’re compromised.

In the next part of this series, we’ll dive deeper into the vulnerabilities around authority and explore how it’s managed today. More importantly, we’ll look at how we can strip authority away, ensuring that no one has unchecked control.

And we’re not just going to shift the burden into another box you’ll have to, well, trust. Instead, I’ll introduce a radically different approach to managing authority—one that could fundamentally reshape how we think about cybersecurity, privacy, and digital ownership.

Trust me. But don’t! Verify.

Original op-ed published here.

Authors:

Michael Loewy is a Co-Founder of Tide Foundation and serves on the advisory board of the Children’s Medical Research Institute.

Yuval Hertzog is a Co-Founder of Tide Foundation and one of the inventors of VoIP.