Security

Your vault is encrypted before it is stored.

StrideAuth separates signing in to your account from unlocking your vault. Vault contents are encrypted and decrypted in your browser; the service stores encrypted records and the metadata needed to operate them.

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.