What happens in your browser
When a vault is created, the browser generates a random vault key. Your master password is processed with Argon2id to derive a key that wraps the vault key. StrideAuth uses XChaCha20-Poly1305 authenticated encryption for vault keys and item contents.
Item names, usernames, passwords, notes, authenticator secrets, recovery codes, card details, and tag names are encrypted before they are sent for storage. Search and filtering over readable item fields happen in the unlocked browser.
What the service stores
The API and database store encrypted vault blobs and non-secret operational metadata such as record identifiers, record types, timestamps, ordering, encrypted blob sizes, and relationships between opaque identifiers. They do not need plaintext vault item fields to list or persist your records.
This design reduces what a database breach or an API process reading the database can reveal about vault contents. It does not make a compromised device, malicious browser code, or malware harmless.
Account sign-in and vault unlock are different
Your account password establishes an authenticated session. Your master password also derives the key needed to unlock the encrypted vault in your browser. These are separate security roles even when the initial signup experience uses one password for both.
An email password reset can restore account access, but it cannot by itself decrypt existing vault contents.
Recovery stays in your custody
Vault setup generates a high-entropy recovery key and shows it to you for safekeeping. A separately derived recovery key can unwrap the same vault key when the password-based wrap is no longer usable.
StrideAuth does not keep the readable recovery key. If you lose both your password and recovery key, StrideAuth cannot restore the plaintext contents of your existing vault. This is an intentional consequence of not retaining a service-side decryption shortcut.
Locking and key lifetime
The readable vault key is held in browser memory only while the vault is unlocked. The current web vault locks after inactivity, shortly after its tab is hidden, when a restored browser page could retain old state, when the tab closes, and when you explicitly lock or sign out.
Browser memory protections cannot defend against a device or browser that is already compromised while the vault is unlocked.
Two-factor authentication
Optional authenticator-app 2FA adds a second challenge to StrideAuth account sign-in. Backup codes provide an alternate sign-in path. The product does not use a trusted-device bypass: when 2FA is enabled, a new sign-in is challenged.
Account 2FA protects authentication. It does not replace vault encryption, your master password, or your recovery key.
Algorithms and current parameters
- Password-based derivation
- Argon2id; current vault profile uses 32 MiB memory, 3 iterations, and parallelism 4.
- Authenticated encryption
- XChaCha20-Poly1305 with a 256-bit key and a fresh 24-byte random nonce per operation.
- Vault key
- 256 random bits generated on the client.
- Recovery key
- 256 random bits generated on the client and placed in the user's custody.
Limits of the model
No security design removes every risk. The current threat model does not claim to prevent:
- Malware, a compromised browser, or malicious extensions reading an unlocked vault
- A compromised deployment serving altered client-side code
- Offline guessing of a weak master password, although Argon2id raises its cost
- Inference from non-secret metadata such as record counts, timing, and encrypted sizes
- A recipient retaining a credential that was deliberately revealed to them
Testing and assurance
The repository includes automated tests for cryptographic wrapping, key derivation policy, tenant isolation, encrypted database fields, security headers, authentication rate limits, 2FA, recovery, and critical browser journeys. StrideAuth does not currently claim an independent security audit or certification.
Report a security issue
Send suspected vulnerabilities to security@strideauth.com. Please do not include passwords, recovery keys, authenticator secrets, session cookies, or decrypted vault contents in the initial message.
For account or product help, use Support and contact instead.