ShorShield Platform Documentation
A quantum-safe enterprise password manager built with post-quantum cryptography, zero-knowledge architecture, and passwordless authentication.
Overview
ShorShield is a quantum-safe enterprise password manager built with post-quantum cryptography and zero-knowledge architecture. The platform addresses vulnerabilities identified in contemporary password management systems, including widely discussed breaches where insufficient key derivation parameters enabled offline attacks against encrypted vaults.
The platform implements NIST-standardized post-quantum cryptographic algorithms (ML-KEM-1024 and ML-DSA-65) alongside a client-side encryption model where decryption keys never leave the user's device. This architectural approach is designed to resist both current attack techniques and potential future threats from quantum computing.
Why post-quantum? Algorithms such as RSA and elliptic curve cryptography, which underpin most contemporary security systems, will become vulnerable to quantum attacks within the foreseeable future. NIST has responded by standardizing post-quantum cryptographic algorithms — ShorShield implements these from the ground up.
Technical Architecture
Core Security Principles
The platform is built upon four foundational pillars that inform every architectural decision:
Post-Quantum Cryptography
NIST-standardized ML-DSA-65 (Dilithium3) for authentication signatures and ML-KEM-1024 (Kyber1024) for key encapsulation — Security Level 3 and Level 5 respectively.
Zero-Knowledge Architecture
All encryption and decryption occurs exclusively on the client device. The server stores only encrypted data and public keys — even a complete database compromise reveals nothing.
Passwordless Authentication
WebAuthn integration with platform authenticators (Windows Hello, Touch ID, Face ID) eliminates traditional password-based authentication vulnerabilities.
Privacy-First Design
Minimal data collection, automatic memory clearing of sensitive information, and cryptographic session binding to prevent session hijacking.
Cryptographic Implementation
The cryptographic layer utilizes the @noble/post-quantum library, providing pure JavaScript implementations of the newly standardized post-quantum algorithms. This enables consistent operation across both server-side Node.js environments and client-side browsers.
Library Selection Rationale
- No FIPS-validated implementations of ML-KEM or ML-DSA are currently available for browser environments. NIST finalized these standards in 2024, and validated modules are still progressing through certification.
- The @noble cryptographic libraries are developed by Paul Miller, a respected figure in the JavaScript cryptography community. The libraries are open source, community-reviewed, and used in production applications.
- Using the same library on both client and server ensures consistency in cryptographic operations and simplifies verification.
- Pure JavaScript implementations are directly readable and auditable without requiring decompilation or specialized tools.
Authentication
ML-DSA-65 keypairs are generated during user registration. The public key is transmitted to the server while the private key remains exclusively in the browser's IndexedDB storage. Challenge-response authentication follows a strict protocol: the server generates a cryptographically random challenge, the client signs it using the stored private key, and the server verifies the signature against the registered public key.
Vault Encryption
Vault encryption employs a hybrid approach combining ML-KEM-1024 with AES-256-GCM. When storing a credential, the system performs key encapsulation against the user's KEM public key to derive a shared secret, then uses this secret as the AES-256 key for symmetric encryption. This provides quantum-resistant key exchange while leveraging the efficiency of symmetric encryption for data protection.
Web Application Architecture
The platform is built using Next.js 16 with React 19, chosen for server-side rendering capabilities and API route functionality. The database layer uses PostgreSQL with Prisma ORM, providing type-safe database access and migration management.
Session management implements HTTP-only cookies with session fingerprinting to detect and prevent cookie theft. Each session is bound to a hash of the client's user agent, causing stolen cookies to fail validation when used from different browsers. Rate limiting is implemented across all authentication endpoints with configurable windows and thresholds per endpoint category.
Threat Model & Security Assumptions
Security systems must be evaluated not only by what they protect against, but also by the assumptions they make and the threats they explicitly do not address.
What ShorShield Protects Against
| Threat | Protection |
|---|---|
| Server-Side Compromise | Complete database access yields only encrypted data and public keys. Private keys exist solely on client devices. Attacker cannot decrypt vault contents, derive credentials, or impersonate users. |
| Network Interception | Even if an attacker intercepts all traffic (e.g., compromised certificate authority), they observe only encrypted payloads and public keys. Challenge-response authentication prevents replay attacks. |
| Quantum Computing Threats | ML-KEM-1024 and ML-DSA-65 are designed to resist attacks from both classical and quantum computers. Addresses "harvest now, decrypt later" strategies. |
| Credential Stuffing | No passwords are used in authentication — there is no password hash to steal and no password to guess. Rate limiting provides additional protection. |
Trust Assumptions
- Browser Trust: The user's web browser is assumed to be a trustworthy execution environment. If the browser is compromised (malware, malicious extensions), an attacker could extract keys or intercept decrypted data. This is a fundamental limitation of any browser-based cryptographic application.
- Origin Integrity: The security model depends on the browser's same-origin policy. Private keys in IndexedDB are accessible only to JavaScript running on the ShorShield origin. Content security policies, input sanitization, and output encoding mitigate injection risks.
- Device Security: Users are assumed to maintain reasonable security hygiene. ShorShield protects data in transit and at rest on servers, but cannot protect against a fully compromised client device.
- Implementation Correctness: The security properties depend on correct implementation of cryptographic protocols. The @noble/post-quantum library provides primitives, and the integration has been developed with security as a priority, though it has not undergone formal third-party audit.
Known Limitations
Cross-Site Scripting (XSS): If malicious JavaScript is injected, it could access private keys in IndexedDB. Multiple layers of XSS prevention are implemented, but this represents the most significant threat to the zero-knowledge model.
- Compromised Client Devices: Malware, compromised OS, or physical access can expose credentials regardless of encryption.
- Social Engineering: Users could be tricked into approving malicious WebAuthn requests. Passwordless design eliminates traditional credential phishing.
- Denial of Service: Rate limiting is implemented, but a sufficiently motivated attacker could disrupt availability.
- Side-Channel Attacks: The JavaScript implementation has not been analyzed for timing attacks, though the @noble libraries implement constant-time operations where possible.
Design Trade-offs
JavaScript Cryptography vs. Native Implementations
Pure JavaScript was chosen over WebAssembly/native modules for:
- No FIPS-validated browser implementations exist for PQC algorithms yet
- Auditability — code is human-readable and directly inspectable
- Cross-platform consistency between client and server
- Performance difference is imperceptible for infrequent cryptographic operations
IndexedDB Key Storage
Private keys are stored in IndexedDB, which is not a secure enclave. Alternatives considered:
- Server-side storage would break the zero-knowledge model
- WebCrypto API's non-exportable keys don't support PQC algorithms
- IndexedDB is the least-bad option preserving zero-knowledge with post-quantum cryptography
Session Fingerprinting
Session fingerprints are based on user-agent hashing — intentionally a defense-in-depth measure, not a primary control. Primary session security relies on HTTP-only cookies, short expiration, SameSite attributes, and server-side revocation.
Features
User Authentication
The authentication system supports multiple stages to accommodate varying security requirements. Users authenticate primarily through cryptographic signature verification, with optional WebAuthn biometric verification as a second factor. The system verifies user status in real-time, immediately invalidating sessions when accounts are revoked.
Password Vault
The vault interface allows users to store, retrieve, and manage credentials. Each credential is encrypted individually on the client before transmission, with only metadata (title, website URL, username) visible to the server. Password decryption occurs exclusively in the browser using the locally stored private key.
Additional security measures: automatic clipboard clearing after 10 seconds when passwords are copied, and memory zeroing of decrypted credentials after display.
Enterprise Administration
Administrative capabilities include:
- User invitation with cryptographically signed tokens
- Real-time user revocation with immediate session invalidation
- Password sharing with end-to-end encryption
- Comprehensive audit logging of security-relevant events
Password sharing: When an administrator shares a credential, the system decrypts it locally, re-encrypts it against each recipient's KEM public key, and transmits individually-encrypted copies. Recipients decrypt using their own private keys — shared passwords maintain the same zero-knowledge guarantees as personal credentials.
Browser Extension
A Chrome extension facilitates credential autofill on websites. The extension communicates with the main application to retrieve matching credentials for the current domain, while actual decryption still occurs within the main application context where private keys are accessible.
Database Architecture
The database schema supports multi-tenant enterprise deployment with the following primary entities:
| Entity | Purpose |
|---|---|
| Company | Organizational containers with subdomain routing, seat management, and status tracking |
| User | Account records storing Dilithium and Kyber public keys, WebAuthn credentials, and role permissions |
| Session | Active sessions with expiration, fingerprint binding, and IP/user-agent tracking |
| VaultItem | Encrypted credential storage with sharing metadata and audit trails |
| AuditLog | Immutable security event records for compliance and incident investigation |
| Invitation | Time-limited, cryptographically signed invitation tokens for secure onboarding |
| UsedNonce | Replay attack prevention via one-time nonce tracking |
Architecture Diagrams
Current Constraints
Platform Availability
The current release is web-first. Mobile applications for iOS and Android are not yet available. The web application functions well on desktop browsers.
Browser Extension Status
The Chrome extension supports basic autofill operations. Features such as automatic login detection, inline password generation, and support for additional browsers (Firefox, Edge, Safari) are under development.
Enterprise Integration
Planned integrations include LDAP/Active Directory, SAML/OIDC single sign-on, and SCIM protocol support. Currently, user management is performed through the administrative dashboard.
Key Recovery
The zero-knowledge architecture means that if a user loses access to their device without backup authentication methods, vault recovery is not possible by design. A secure social recovery mechanism is under design consideration.
Security Audit
The platform has not yet undergone formal third-party security audit. Organizations with strict compliance requirements should be aware of this limitation.
Roadmap
Near-Term (3–6 Months)
- Full browser extension with autofill, login detection, and password generation
- Firefox and Edge extension support
- iOS and Android mobile applications with secure enclave key storage
- Biometric authentication via Face ID, Touch ID, and Android fingerprint APIs
Medium-Term (6–12 Months)
- LDAP & Active Directory synchronization
- SCIM support for automated user lifecycle management
- SAML 2.0 and OpenID Connect single sign-on
- Secure social recovery mechanism for key loss
Long-Term (12+ Months)
- SOC 2 Type II certification
- ISO 27001 compliance
- Self-hosted deployment option for data sovereignty
- Hardware security key integration (YubiKey direct)
- Modular cryptographic architecture for algorithm updates