Proton Mail
Summary
ExpandProton Mail's Pass component is a browser-based password manager built as a React/TypeScript single-page application with a layered cryptographic architecture. The codebase spans authentication flows (SRP-based password login, FIDO2/WebAuthn, TOTP two-factor, and external SSO with device confirmation), a multi-mode session locking system (PIN, password, biometrics, desktop), password generation delegated to a Rust/WASM core, and a comprehensive cryptographic library implementing a hierarchical key management scheme. The architecture follows a clear separation of concerns: UI components handle presentation and state orchestration via Redux, shared libraries encapsulate cryptographic operations through a `CryptoProxy` worker pool, and security-critical credential verification is delegated to server-side APIs. Core cryptographic primitives are provided by `pmcrypto`, the Web Crypto API, and `@protontech/pass-rust-core`, with the TypeScript layer serving as an orchestration and configuration surface rather than implementing custom algorithms.
The codebase demonstrates consistently strong security engineering practices across all audited sections. The key hierarchy — user keys protecting vault keys, vault keys protecting item keys, item keys protecting content and file keys — employs AES-GCM authenticated encryption with domain-specific `PassEncryptionTag` constants that prevent cross-protocol ciphertext confusion. Signature verification is enforced on all externally-sourced decryption paths, including vault invite flows, native messaging between extension and desktop clients, and share key operations. Password change flows correctly sequence event manager suspension, key salt and passphrase derivation, SRP-authenticated server updates, session mutation, and cache invalidation, with a defensive forced-signout fallback if session mutation fails after a successful server-side password change. The authentication state machine guards against concurrent form submissions via `useLoading` hooks and `createFlow` validation, manages WebAuthn request lifecycles with `AbortController`, and uses DOMPurify with restrictive tag and attribute allowlists for rendering server-provided content. Offline credential verification employs Argon2 with recommended parameters, and sensitive session fields are encrypted in a blob before persistence with integrity verified via SHA-256 digests.
The overall security posture of the audited codebase is strong. No vulnerabilities were identified across approximately 130,000 lines of code spanning authentication, cryptography, session management, and password generation components. The architecture's consistent delegation of cryptographic operations to established, audited libraries rather than custom implementations significantly reduces the attack surface. The fork-based SSO authentication flow and the `postMessage` origin validation in the external SSO login path represent the areas of highest inherent risk due to their cross-origin trust boundaries, and these should receive continued scrutiny as the SSO integration evolves. The encrypted session persistence model, Argon2-based offline key derivation, and SRP protocol usage collectively provide robust protection for credential material at rest and in transit.
Findings
No issues identified
Conclusion
ExpandThe Proton Pass codebase exhibits a high degree of security maturity across all audited components. The consistent application of defense-in-depth principles is evident throughout: hydration assertions guard every stateful cryptographic operation against use of uninitialized context, the CryptoProxy worker pool synchronizes key state across all workers during import and generation operations, server-time offsets are applied to signature verification and key generation to mitigate local clock drift, and legacy compatibility paths (such as the deprecated 16-byte IV scheme and trailing-space signature normalization fallback) are maintained without compromising the security of new operations. The TypeScript type system is leveraged effectively for security purposes, notably the discriminated union pattern for GeneratePasswordConfig that prevents misconfiguration between random and memorable password modes at compile time, and the AuthStep enum that enforces valid state transitions in the authentication flow.
The areas of highest residual risk are concentrated at trust boundaries rather than within individual components. The fork consumption flow’s state validation, the postMessage origin checking in the SSO popup communication channel, and the session lock retry count stored outside the encrypted blob represent the primary vectors where an attacker with specific positioning — script execution within an SSO redirect chain, local storage access, or control of a malicious extension context — could potentially weaken security guarantees. These are defense-in-depth concerns rather than directly exploitable attack paths, as the server-side API enforces the authoritative authentication and authorization decisions, and Argon2’s computational cost provides the primary defense against local brute-force attempts independent of client-side retry counting.
The codebase is well-suited for production deployment in its current form. The absence of any low-severity or above findings across the authentication, cryptographic, session management, and UI layers reflects a codebase that has benefited from deliberate security-focused design decisions and consistent implementation discipline. For continued assurance, the recommended next steps are to enforce minimum encryption version 2 for new file operations to retire the legacy chunk encryption scheme, to harden the postMessage origin validation in the SSO flow to use strict equality rather than the current conditional logic, and to ensure that the Rust/WASM core (@protontech/pass-rust-core) and the underlying pmcrypto library receive dedicated cryptographic review, as the security guarantees of the entire key hierarchy ultimately depend on the correctness of these foundational primitives.
On-Chain Verification
Compare these values with the on-chain attestation
Verify: download the markdown and compare the hash
sha256sum proton-mail.md
Legal Disclaimer: This report covers the code submitted for analysis. It does not account for infrastructure, deployment configuration, third-party dependencies, or changes made after the audit date. Automated analysis may produce false positives or miss context-dependent vulnerabilities. audited.xyz provides this report “as is” without warranty of any kind.