BLOG

This Aussie start-up plans to make Medibank-style breaches impossible

14 Nov 251 min read

The catastrophic data breaches that exposed millions of Australians’ personal information at Medibank and Optus revealed a fundamental flaw in how oranisations protect data - one that even the best cybersecurity tools can’t fix.

Now an Australian start-up claims it has solved the problem that made those breaches so devastating, and the world’s leading insurance marketplace is backing the technology.

Tide Foundation has announced a partnership with Lloyd’s-backed underwriter Becco that will provide preferential insurance coverage to companies adopting technology designed to eliminate the “choke points” that turned the Medibank and Optus incidents from simple breaches into national crises.

“Things will just keep getting worse because looking to AI as salvation is the wrong place to be searching. Trying to stop someone getting in is almost futile. You have to make sure that when it happens, it’s not consequential.”

Read the full story.

News & views

02 Jan 26

KeyleSSH: A PAM With No Single Point of Vulnerability

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 CryptographyKeyleSSH 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 CodeProper 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: 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 AdminBecause 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 StatusWhile 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.SummaryKeyleSSH 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.LinksSource Code: github.com/sashyo/keylesshLive Demo: demo.keylessh.comTideCloak SDK: docs.tidecloak.com

Read more →
08 Dec 25

Beyond Patching: Mitigating RCE with Architectural Cryptography

TL;DRHow to shut down the next "React2Shell" by removing its target. 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 AuthorityIn 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 GoalTraditional Architecture (Vault on Server)Ineffable Cryptography ArchitectureAttacker Action: Executing a shell command: cat /etc/secrets/db_password.envAttacker Action: Executing a shell command: cat /etc/secrets/db_password.envResult: 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 DevelopersEvery 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 QuestionsWhat are the affected frameworksCVE-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 RouterWakuParcel 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

Read more →
29 Sep 25

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

TL;DRDeclare:const { login } = useTideCloak(); Add this:<p><button onClick={login}>Login</button></p>  That's it. No password storage, no hashing logic.Some contextTraditional 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 approachesPassword 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 worksInstead 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 thisCreate a React app using Vitenpm create vite@latest tidecloak-react -- --template react-ts cd tidecloak-react npm install @tidecloak/react Get TideCloak runningRun 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 instanceTide offers a free developer license for up to 100 users.Open: http://localhost:8080/admin/master/console/#/myrealm/identity-providers/tide/tide/settingsSign 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 adapterGo to Clients → mytestSet Valid redirect URIs to http://localhost:5173/*Set Web origins to http://localhost:5173In 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 rootEdit src/main.tsxAdd 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 propertiesTideCloak 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 limitationsProtects against:Database breaches revealing credentials/hashesInsider access to user password materialToken replay in MITM scenarios (browser-bound, DPoP-style proof)OAuth/IdP provider compromise leaking user credentialsDoesn't protect against:Keyloggers/malware on user devicesVery weak passwordsMajority network compromise above threshold (≥14/20)Current limitations:Internet connectivity required for authenticationAlpha stage - not recommended for production yetIntegration simplicityThe 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 onWe're in alpha and looking for feedback on:Developer experienceClarity of the approachBugs and feature requestsTideCloak's code is open source - we welcome security reviews and integration feedback.Dive into the codeOne-Click Demo: https://codespace.new/tide-foundation/tidecloak-playground?quickstart=1Example React project: https://github.com/tide-foundation/tidecloak-gettingstartedSDK: https://docs.tidecloak.com/Join the dev community: https://discord.gg/XBMd9ny2q5We'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.

Read more →
10 Sep 25

The God Mode Vulnerability That Should Kill "Trust Microsoft"

How One Token Could Have Compromised Every Microsoft Entra ID Tenant on Earth, And Why It’s Time for Authorityless SecurityRecently, 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” BreachesThe 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 VectorLarge 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 VulnerabilityFirst, 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 SecurityWe 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 dataNo administrator, no matter how privileged, can override the system without oversightNo supply chain compromise can grant universal accessNo vulnerability, no matter how critical, can provide god-mode to attackersThis 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 credentialsAuthorization requires cryptographic consensus from multiple independent serversCryptographic 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 nodesEven if an attacker compromises the IAM or multiple nodes holding key fragments, they cannot forge access or decrypt dataThe 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 AskNext 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 AuthoritylessThe 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

Read more →
04 Jun 25

Ghost in the Network

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.

Read more →
19 May 25

Another security patch. Another missed opportunity.

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 overEvery 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-aidsWhile 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-auth2023-27997 ("XORtigate") – Heap overflow, again pre-auth on SSL-VPN2022-40684 – Bypass the admin API, create your own super-admin2020-12812 – Change username case to dodge FortiToken 2FA2018-13379 – Path-traversal that leaks raw VPN session files and passwordsShooting ourselves in the footThis 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 needsYet, in practice, we keep building systems with total, unverified power because "that's how it's always worked."A better modelInstead 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"Traditional modelDecoupled-authority modelProduct stores data and enforces accessProduct stores opaque data; outside service enforces accessBreach = data + decision powerBreach = opaque data without the keyPatching cycle never endsEntire class of auth-bypass exploits disappearsA way forwardThe 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.

Read more →
01 Jul 25

Part 1: It’s time for platform developers to rethink cybersecurity

 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.Every developer's nightmareYou 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 thinkThere 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 TrustLet 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.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 2024Michael 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.Series shortcuts:Part 1: It's time to rethink cybersecurity for platform developersPart 2: It's cybersecurity's kryptonite: Why are you still holding it?Part 3: How nature holds the key to cybersecurity's futurePart 4: I got 99 problems, but a breach ain't onePart 5: Future proofing your platform 

Read more →
04 Nov 24

Tide Wins Cyber Award for Ineffable Cryptography

Tide Foundation has taken out the Cybersecurity award at the InnovationAus 2024 Awards for Excellence for its breakthroughs transforming the inevitability of a cyber-attack to the impossibility of them occurring.  The InnovationAus 2024 Awards for Excellence were presented at a black-tie gala dinner at The Venue Alexandria in Sydney on Wednesday night. Tide Foundation was awarded the Cybersecurity gong for its flagship TideCloak product, a world-first identity, immunity and access management system that can protect from malicious cyber attacks.  The Cybersecurity category was sponsored by the Australian Computer Society. The award was presented on the night by Australian Computer Society director of corporate affairs and public policy Troy Steer. TideCloak is based on Tide Foundation’s breakthrough technology, dubbed “ineffable cryptography”, allowing a user’s data and devices to be secured with keys that no-one will ever actually hold in full, making it impossible for malicious actors to access them.  This move away from the centralisation of cybersecurity does away with the key flaw of current approaches in that “someone has to be trusted with the keys”, Tide Foundation co-founder Michael Loewy said.  “It’s a fundamental breakthrough in cryptography, lab-tested by three of Australia’s top universities,” he said.  “Ineffable cryptography solves the fundamental trust problem in a way that wasn’t possible before and provides a new path to solving some of the world’s most pressing challenges, like cybersecurity and privacy – particularly with the explosion of AI.”  Tide Foundation has landed an Australian Research Council grant, and is also working with leading institutions including Wollongong University, RMIT University and Deakin University.  It has also partnered with NTT Global, which is using TideCloak with its enterprise and prospective clients.  The end goal is for TideCloak to eventually become the new global standard for cybersecurity, digital ownership and authority.  The InnovationAus 2024 Awards for Excellence are supported by the Australian Computer Society, Investment NSW, Department of Industry, Science and Resources, Technology Council of Australia, TechnologyOne, National Artificial Intelligence Centre, CSIRO’s ON Innovation Program, Reason Group, Q-CTRL, University of New South Wales, South by South-West Sydney and IP Australia.   Read full article

Read more →