wowkey Security Whitepaper
A technical description of the current wowkey client security model: key hierarchy, encrypted sync, device protection, and credential-provider safeguards.
This paper describes the current wowkey client and browser-extension security model, trust boundaries, and implemented safeguards. It explains how keys are created and used, which data is encrypted before synchronization, and which operational metadata the synchronization service still needs to process.
This paper is not an absolute security guarantee for every environment and is not a substitute for an independent security audit. It should be revised when the product, platform, or protocol changes materially.
1. Scope and Security Claims
wowkey uses a client-side encryption model: sensitive vault fields are encrypted and decrypted by the client or browser extension, and the synchronization service does not need their plaintext in order to store, deliver, or synchronize them. A successful sign-in alone does not provide a plaintext vault; the client must also use keys derived from the master password to open the user key and vault contents.
That claim has an explicit boundary. The synchronization service does not process ciphertext alone. It must retain and process operational metadata for accounts, items, folders, organizations or collections, authorization, synchronization, ordering, deletion, and sharing. This paper distinguishes encrypted content from service-visible metadata instead of treating them as the same thing.
2. Architecture and Trust Boundaries
The model has four boundaries:
- Client, browser extension, and master password. The master password is used by the client or extension to derive the master key, decrypt the account key, and open the vault. The sign-in request uses a value derived from the password and master key rather than placing the raw master password directly in its password field.
- Synchronization service. The service authenticates and authorizes accounts, stores synchronization objects, and runs synchronization. It receives encrypted vault fields while processing identifiers, timestamps, permissions, and other metadata necessary for that work.
- Device and platform credential interfaces. The local database, system keystore, biometrics, autofill, and credential-provider extensions operate within the device and operating-system boundary. An unlocked device, an app that has been given autofill data, or an attacker with system-level control are outside the protection provided by the claim that the sync service does not need plaintext vault fields.
- Web pages and extension runtime. The browser extension’s background and extension pages are trusted extension contexts; content scripts carry only restricted operations between those contexts and web pages. A web page is not a trusted vault context and cannot call sensitive extension-background interfaces directly.
3. Data Classification
Encrypted vault content
The following content is transformed into encrypted strings by the client before it is written to synchronization objects:
| Category | Representative fields |
|---|---|
| General item content | Item name, notes, tags, custom-field names and values |
| Login credentials | Username, password, password history, website or app URIs, URI checksums |
| Second-factor material | TOTP secret |
| Passkeys | Credential ID, key type/algorithm/curve, private-key value, relying-party and user metadata, counter |
| Other sensitive items | Sensitive fields in cards, identities, and SSH keys |
| Attachment-related metadata | Attachment file names and attachment key material |
An item can have independent item key material. That item key is itself protected by a higher-level account or organization crypto context. The current implementation therefore synchronizes encrypted fields and objects; it does not upload the whole vault as one opaque file.
Service-visible operational metadata
The following classes of information are processable by the service so that synchronization and authorization can work. Exact fields depend on the feature, but they are not plaintext vault content from the preceding table:
| Purpose | Representative metadata |
|---|---|
| Account and authorization | Account ID, email, organization/collection/folder IDs, membership or item permissions, subscription and configuration state |
| Synchronization and lifecycle | Item type, creation/revision/deletion timestamps, remote ID, deletion state, folder and collection relationships, favorite state |
| Secure-share controls | Share access ID, type, expiration and deletion times, current/maximum access count, disabled state, hide-email option |
The service may therefore learn operational facts such as item counts, types, and change timing. This paper does not claim that it has no visibility into that metadata.
4. Key Hierarchy and Master-Password Derivation
The client obtains the account’s key-derivation configuration during pre-login, then derives a 32-byte master key from the master password and an email-derived salt. The system supports PBKDF2 and Argon2id modes. PBKDF2 uses the normalized lowercase email as its salt and the account-configured iteration count; Argon2id uses its configured iteration count, memory, and parallelism. Newly registered accounts currently default to PBKDF2 with 600,000 iterations.
HKDF then derives separate encryption and MAC keys from the master key using distinct information labels. During registration, the client generates a random 64-byte user symmetric key and stores it encrypted with keys derived from the master password. Supported flows may also create an RSA-2048 key pair: the public key is stored as public material and the private key is encrypted with the user symmetric key.
This creates a hierarchy: the master password derives the master key; the master key protects the user symmetric key; user or organization crypto contexts protect item keys and item contents. Master-password strength still determines the cost of offline guessing attacks, so users should choose a unique and sufficiently long master password.
5. Vault Encryption and Integrity
Current synchronized writes use AES-256-CBC encryption with HMAC-SHA-256 integrity verification. Ciphertexts contain an internal format marker so that clients can select compatible decryption and integrity-verification rules as formats evolve.
| Property | Current implementation |
|---|---|
| Encryption | AES-256-CBC with PKCS#7 padding |
| Integrity | HMAC-SHA-256 over the IV and ciphertext |
| Key material | 64 bytes: first 32 bytes for AES, final 32 bytes for MAC |
| Random initialization vector (IV) | A fresh random 16-byte value for each encryption, preventing identical content from producing identical ciphertext |
The client verifies the MAC before it decrypts. This is an encrypt-then-MAC construction; CBC mode is not described here as an authenticated-encryption mode. The client retains read compatibility for earlier ciphertext formats.
6. Sign-In, New Devices, and Session Boundary
Before sign-in, the client completes master-key derivation locally from the account configuration and creates the derived verification value required for sign-in. The raw master password is not sent as that request’s password field. After authentication, the client downloads encrypted account material and vault objects. It can decrypt the associated content only after it opens the user key protected by the master-key-derived material.
Access and refresh tokens are used for later authenticated requests. The client also handles account-security changes and invalid sessions; when protected account material cannot be opened under the current session, it treats that state as requiring a new session. A new device or cleared local state still needs the master password capable of deriving the correct master key to restore vault access.
7. Encrypted Synchronization, Consistency, and Deletion
The synchronization flow establishes decryption contexts on the client: downloaded objects are decrypted locally, and local changes are encrypted before upload. The service can therefore store encrypted fields alongside the preceding operational metadata without reading item names, passwords, or TOTP secrets for synchronization.
Items use remote identifiers, revision times, and deletion state during synchronization. The client applies item-specific merge rules to local and remote versions: mergeable content is merged, while other conflicts are handled according to revision state. Deletions are also propagated as synchronization state. This aims for multi-device consistency. It is not a guarantee of availability, a complete backup, or rollback protection against a malicious or unavailable service. Users should keep encrypted backups and verify synchronization after important changes.
8. Local Storage, Locking, and Biometrics
Once the master session is created, the local vault database on every platform is opened with encryption using the session master key. Android and iOS use SQLCipher. The Android database is stored in an app directory excluded from backup; iOS verifies that SQLCipher is active when opening the database. This protection, together with operating-system app isolation, reduces exposure from static database files on a lost device. It does not protect a device that is already unlocked, compromised by malware, or controlled at the system level.
Biometric unlock is a local convenience mechanism. It is not remote identity proof and does not replace the master password:
- Android: An Android Keystore AES key requiring
BIOMETRIC_STRONGauthentication encrypts locally stored unlock material. - iOS: A Keychain item is available only while the device is unlocked, bound to that device, and tied to the current biometric enrollment. A change in the enrolled biometric set makes that item unavailable until it is configured again.
Biometric templates are handled by the operating system. The client does not send fingerprint or face data to the synchronization service.
9. Autofill, TOTP, and Passkeys
Autofill matches saved URIs to a current website or app target. Matching supports domain, host, starts-with, exact, regular-expression, and never-match rules, and can account for equivalent domains and Android/iOS app URIs. When the vault is locked, the Android autofill service offers an unlock path rather than directly providing credentials. URI matching helps reduce incorrect suggestions, but users must still verify the website, app, and account. It is not an absolute defense against phishing or malicious apps.
The browser extension constrains autofill to an extension-initiated, controlled flow. A web page cannot directly request credentials from the extension background; a content script can request only its granted operations, and the background limits message capabilities by sender context. Before executing a fill command, the extension rechecks that the current document, URL, origin, and frame still match the context in which the candidate was generated, and applies a short expiration. Sandboxed iframes are refused. An HTTPS credential filled into an HTTP page or a cross-origin iframe requires user confirmation. The extension’s inline UI is rendered in an extension-page iframe; its messages validate source, extension origin, and a session nonce to reduce the risk that a page can impersonate extension UI.
The TOTP secret is stored as an encrypted field of the login item. The client must unlock the vault before it can read that secret for the relevant verification flow.
Passkeys use platform credential-provider interfaces. On Android, creation and use validate the relationship between relying-party ID and calling origin, include challenge and origin in client data, and use P-256 / ES256 for key and signature processing. The iOS credential-provider extension handles the relying-party identifier, client-data hash, and user-verification requirement before completing an assertion or registration response. Passkey private keys and related metadata remain encrypted vault fields. Where a request requires user verification, the flow must complete that verification before continuing. The relying-party server remains responsible for validating authentication responses and applying its own account-security policy.
10. Browser Extension Runtime and Session Boundary
The browser extension reuses the master-password derivation, protected user key, item-key, and encrypted-synchronization model described above. After unlock, the user key and item keys are held by a Rust/WASM key store. The extension’s ordinary TypeScript session holds only opaque handles and key-slot references. Passwords and TOTP secrets do not enter the long-lived credential list; they are decrypted per item only for explicit actions such as filling, displaying, copying, or generating a verification code.
The extension does not use a SQLCipher database. It can cache still end-to-end-encrypted synchronization objects in extension storage and stores account, KDF, protected-user-key, token, and timeout operational material there. Where available, it restricts local-storage access to trusted extension contexts. That protection is not equivalent to native-app database encryption when a browser profile or the extension itself is compromised: cached ciphertext still requires the correct key material to decrypt, while tokens and similar operational material must be treated as account-access material.
To tolerate Manifest V3 background-worker reclamation, the extension can retain a short-lived session-restoration wrapping key in browser session storage and store the restoration payload sealed with AES-GCM. This supports background recovery within the current browser session; it is not a permanent passwordless-unlock mechanism. The associated material is cleared when restoration is not allowed.
When local unlock is configured, the extension uses Native Messaging to establish a temporary encrypted channel with a locally installed unlock component. System-level biometric verification and protected key material are handled by that component and the operating system. The extension handles a short-lived copy of the user key only during a single restoration flow and clears it after use.
11. Secure Sharing Model
Implemented text shares use separate random 16-byte share-key material, expanded through HKDF into a 64-byte encryption/MAC key. Share title, notes, and text content are encrypted with the share crypto context before synchronization; the share key is protected by the account crypto context in the owner’s synchronized data.
An optional share password is not uploaded as the raw password. The client derives a verification hash with PBKDF2 using the share key as salt and 100,000 iterations. Expiration and deletion times, access limits and counts, disabled state, and similar controls remain service-processable share metadata.
12. Threat Model, Non-Goals, and User Responsibilities
The model is designed to reduce the risk that a synchronization service can directly read encrypted vault fields. Independent keys, integrity verification, local database encryption, browser-extension isolation, and platform-unlock capabilities add protection against common storage and post-transfer exposure risks. It does not promise to defend against:
- An attacker who obtains an unlocked device, an unlocked vault, the master password, or plaintext from the client process;
- A malicious or compromised synchronization service causing denial of service, deleting data, hiding changes, altering visible metadata, or replaying an older valid synchronization object;
- A user filling or sharing credentials with the wrong website, app, or person;
- A target page’s scripts reading credentials after the user confirms browser autofill and the values have been written into that page’s form;
- A browser profile, browser process, extension installation, or local unlock component being read, replaced, or controlled by an attacker;
- A relying party’s own authentication flaws, account-recovery process, or server-side breach;
- Vulnerabilities in the device operating system, hardware, third-party keyboard, browser, or credential interface.
Users should choose a unique strong master password, install operating-system and app updates promptly, configure URI matching and share lifetimes carefully, and retain recoverable encrypted backups. Loss of the master password or control of an unlocked device cannot be automatically remedied by the synchronization encryption described here.
13. Maintenance and Change Control
This paper records the current implementation; it is not a permanently frozen protocol specification. The following changes require a security review and a whitepaper update: key-derivation parameters or defaults, ciphertext format, key hierarchy, synchronization data classification, local-database protection, browser-extension permissions and message boundaries, WASM key handling, session restoration, the native unlock channel, platform credential interfaces, sharing flows, and any change to service-visible information.