Live Webinar: Achieve 100% SaaS Visibility & Zero Passwords (No Integrations) | May 13 |

When SSO becomes an Attack Surface Part 2

Recap: Why Traditional SSO Becomes an Attack Multiplier

In Part 1, we examined how traditional SSO architectures unintentionally became identity amplification systems. Centralized identity providers, reusable session tokens, and transitive federation trust created a structural condition: one successful compromise often unlocks multiple applications. Modern attacks exploit this condition directly. They do not break cryptography (or hack); they capture authentication material and reuse it to login.

Adversary-in-the-Middle (AiTM) campaigns intercept real authentication flows and harvest session cookies. Golden SAML attacks mint valid assertions after compromising a federation authority or OAuth token theft enables replay until expiration. In each case, the underlying weakness is that authentication artifacts are reusable across systems until expiration.

Unixi changes the security model by eliminating reusable authentication material entirely. Authentication becomes deterministic computation rather than retrieval or storage. No passwords are stored, and no session secrets are persisted for later reuse. Instead, credentials are deterministically derived per application.

Conceptually:

  • The user authenticates once to Unixi (passkey, or their organization’s Identity Provider (IdP), in accordance with the enterprise’s security policies such as MFA or conditional access).
  • The target application identity is canonicalized (domain, tenant, policy).
  • An application-specific secret is derived through Key-Derived Authentication (KDA).
  • The credential is formatted to meet the target system’s policy.
  • Invisible, secure, automatic authentication.

Unixi Robustness against SSO Attacks

Before examining the cryptographic construction and identity security in detail, it is useful to express Unixi’s authentication model at a conceptual level. The following pseudocode is illustrative only and does not reflect implementation details. Its purpose is to highlight the security invariants enforced by the design.

 

Security properties enforced by this flow:

  • Authentication material is derived per application, not reused
  • No credentials are stored, shared, or user-managed
  • IdP authentication (if used) does not propagate access
  • Compromise of one derived secret does not enable lateral movement (per-app key)

How Unixi Changes the Outcome of AiTM

AiTM succeeds in traditional environments because it captures bearer artifacts. MFA validates the login event, but once a session cookie or OAuth token is issued, it becomes a reusable credential until expiration (as described in Part 1). The attacker does not need the password anymore. Federation then magnifies impact by granting access across multiple SaaS systems from a single compromised session.

Unixi alters this dynamic in three main structural ways.

  1. No Stored Credentials – Users do not know the application credentials, and they do not type them. Since they do not reuse them, there is nothing to write down. This removes a large portion of social engineering surface area.
  2. Nothing to Phish or Reuse – Even if an attacker proxies the initial authentication event, there is no reusable password database to exfiltrate and no static credential to replay across services. Credentials are not retrieved from storage, they are deterministically computed per application.
  3. Fully Automated Authentication – Authentication submission is automated by the extension. Users do not manually enter application secrets into web forms. This eliminates the chance of reverse-proxy phishing flows that depend on user interaction with credential prompts.

Limiting Lateral Movement by Removing Transitive Trust

The most damaging aspect of identity compromise is not initial access – it is lateral movement. In federated SSO models, trust is transitive: successful authentication to the IdP often implies access to many downstream applications. Golden SAML and Kerberos ticket forging demonstrate how minting valid authentication material at one authority can unlock an entire environment.

Unixi removes transitive authentication trust at the application layer.

  1. No Implicit Federation Unlock – Authentication to an identity provider does not automatically grant SaaS access. Each system requires independent derivation of authentication material. Trust does not propagate automatically across applications.
  2. System-Specific Derived Authentication – Every credential is bound cryptographically to an application identity. Even if one system is compromised, its derived credential is useless elsewhere. Replay across SaaS environments fails because the derivation inputs differ.
  3. Localized Impact – Compromise of one application does not collapse the enterprise identity boundary. Authentication failures remain localized. Blast radius is constrained by design rather than by monitoring policy.

Cryptographic Aspects of Unixi’s Key-Derived Authentication (KDA)

Unixi’s Key-Derived Authentication (KDA) is designed to address structural weaknesses in password- and token-based authentication rather than to optimize password storage. The cryptographic goal is to eliminate reusable authentication material while preserving deterministic access for legitimate users.

Unixi’s cryptographic model relies on separation of trust domains rather than a single secret. Security emerges from the composition of multiple independent inputs, each enforcing a distinct boundary.

  1. User Key – Binds authentication to the user’s base identity (passkey, or optional IdP) without exposing application credentials.
  2. Company Key – Establishes an organizational boundary, preventing cross-tenant credential replay and enabling centralized rotation.
  3. System Key – Cryptographically isolates each application, ensuring credentials derived for one system cannot be reused elsewhere.
  4. Employee Key – Adds per-employee personalization, preventing credential sharing.

No single key is sufficient to derive valid credentials. Compromise of any individual component does not collapse the system, as shown from “2.2. Limiting Lateral Movement”.

The derivation process applies a one-way cryptographic hash (e.g., SHA-512) to the concatenated inputs:

derived_secret = H(user_key ∥ company_key ∥ system_key ∥ employee_key)

This enforces key security properties:

  • Preimage resistance, preventing recovery of input keys
  • Avalanche effect, ensuring small input changes produce unrelated outputs
  • Uniform distribution, preserving entropy across the output space

Because no credentials or hashes are stored, there is no database to steal, no material to crack offline, and no reusable artifact to replay across systems.

Unixi mitigates brute-force and guessing attacks by eliminating offline verification entirely: no passwords, hashes, or encrypted credentials are stored, leaving attackers without an oracle to validate guesses at scale. Instead of relying on password length alone, security derives from the combined entropy of multiple independent keys (H1, H2, …, Hn) whose one-way derivation yields effective entropy approaching ∑Hᵢ. Because derived credentials are bound to a specific application context and never reusable across systems, exhaustive guessing is computationally infeasible and replay-based lateral movement is structurally constrained.

Conclusion

Traditional SSO concentrated identity risk by combining centralization, reusable authentication artifacts, and transitive federation trust. Modern attacks exploit those structural properties rather than weaknesses in cryptography.

Unixi changes the outcome by removing reusable authentication material and eliminating implicit identity propagation. Authentication becomes deterministic, system-specific, and non-transitive. Compromise, if it occurs, remains localized rather than cascading across the enterprise. Security is no longer dependent solely on detection and policy enforcement. It is enforced at the architectural layer itself.

Request a free trial to see it in action.

Explore more

Category Icon
Blog
Reuvein Vinokurov
March 9, 2026