Skip to content
OTPManager
ProductSecuritySupportSource
Home/Security architecture

Security architecture

Designed for a stolen vault, not a trusted cloud.

OTPManager encrypts the vault before it reaches persistent or remote storage. This page documents the current protections and the threats they cannot solve.

Architecture for vault format v4 · Updated August 22, 2026

Vault encryption

  • A random 256-bit data key encrypts the compressed vault with AES-256-GCM.
  • Your master password derives a separate wrapping key using Argon2id 1.3 with a 128-bit random salt, 64 MiB memory, 3 iterations, and parallelism 4.
  • The wrapping key encrypts the vault data key with AES-256-GCM. Changing the master password can rewrap the data key without weakening vault-data encryption.
  • Format, cipher, compression, key identifier, and key-wrap parameters are authenticated as additional data so silent metadata tampering is rejected.

Each encryption operation uses a fresh random IV where required. The current encrypted envelope and vault-data schema are version 4.

Unlock sessions and quick unlock

After a successful unlock, browser session storage temporarily holds the unwrapped 256-bit data key and activity metadata—not the master password. Manual lock, configured auto-lock, and browser-session shutdown clear that session state.

Where supported, optional quick unlock uses the WebAuthn PRF extension to wrap the same data key with material associated with a local authenticator. It does not turn OTPManager into an operating-system keychain and remains subject to browser and device security.

Remote storage boundary

WebDAV and S3-compatible providers receive encrypted envelopes and encrypted backup snapshots. Credentials are stored inside the encrypted vault. Connections require HTTPS by default, except explicit loopback addresses for local development. The clients reject unsafe paths or object keys, embedded endpoint credentials, and cross-origin WebDAV redirects, and apply response-size, item-count, and timeout limits.

Encryption does not hide every metadata signal from the provider. It may still observe IP address, timing, path, and ciphertext size.

Web-page isolation

The page content script is given only the minimum data needed for detection and filling. It cannot read the vault directly and does not receive TOTP seeds or sync credentials. Extension pages use a restrictive content security policy and load executable code from the extension package.

Threat-model limits

  • A weak or reused master password can still be guessed; Argon2id raises the cost but cannot create entropy.
  • Malware, a compromised browser process, a controlled device, or a local actor able to debug the unlocked extension is inside the trust boundary.
  • A malicious website may observe a code after you intentionally place it into that website’s field.
  • Remote providers can delete or roll back objects. Backups and conflict checks reduce accidental loss but do not replace independent recovery copies.
  • No software security statement is a guarantee that vulnerabilities do not exist.

Report a vulnerability

Please email samler@foxmail.com with “OTPManager security report” in the subject. Include the affected version, browser, reproducible steps, impact, and a safe proof of concept. Do not include real TOTP secrets, passwords, remote-storage credentials, or other people’s data.

Coordinated disclosure: allow reasonable time to investigate and publish a fix before public disclosure. Good-faith research that avoids privacy harm, service disruption, and data destruction is welcome.
SecurityVault encryptionUnlock sessions and quick unlockRemote storage boundaryWeb-page isolationThreat-model limitsReport a vulnerability
OTPManager

Codes are encrypted locally. You choose where sync goes.

PrivacyData & permissionsSecuritySupport
© 2026 OTPManagersamler@foxmail.com