iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
You can build the cryptographic core of a browser vault with WebCrypto alone: a key derived from the master password, AES-GCM for authenticated encryption, and IndexedDB for storage, with no third-party cryptography library. What WebCrypto cannot give you is zero-knowledge by itself. That property belongs to the whole system, including what the server receives, what it can observe, what the delivered JavaScript is trusted to do, and what happens when the page or the device is compromised. This guide walks through each primitive’s role and marks where its guarantee stops.
What WebCrypto gives you, and what it does not
MDN Web Docs describes the Web Crypto API as providing “a number of low-level cryptographic primitives. It’s very easy to misuse them, and the pitfalls involved can be very subtle.” (MDN Web Crypto API) In practice that means the API gives you encryption, key derivation, hashing, and random values, but it does not decide your key hierarchy, your recovery model, your storage policy, or your trust boundary. Those are design decisions you make, and mistakes there can make the whole system insecure even when every primitive is used correctly.
The API is also available only in secure contexts. In practice that means your vault must be served over HTTPS, or from localhost during development. Check this before any other step: if window.isSecureContext is false, crypto.subtle is unavailable and the vault cannot start.
Define the zero-knowledge boundary before writing code
“Zero-knowledge” here means that, under a stated threat model, the server cannot read vault contents or the keys that protect them. It is a claim about data flow, so write the answers to these questions down first:
#1 Best Overall
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
- Does the server receive the master password, a derived key, or only ciphertext and public parameters?
- Which metadata stays visible to the server: account identifier, record count, record sizes, timestamps, and access patterns?
- Who delivers the JavaScript that performs encryption, and how could a user detect that a release was changed?
- What can an attacker do through cross-site scripting on the vault origin while the vault is open?
- What happens if the device is compromised while the vault is unlocked?
- Can a user regain access without the master password, and which party gains decryption capability when they do?
If the answers include “the server holds a key,” “the delivered code is trusted without verification,” or “a reset flow restores access,” the accurate label is a client-side encrypted vault with stated exceptions. That is still a useful design, but it is not an unqualified zero-knowledge system.
Threat model: what each risk requires
OWASP’s Cryptographic Storage Cheat Sheet makes threat modeling the starting point for cryptographic storage design, and covers generation, storage, rotation, and decommissioning of keys (OWASP Cryptographic Storage Cheat Sheet). The table below separates each threat from what WebCrypto contributes. A cell that reads “nothing” means the API does not address that threat at all.
| Threat | Design decision you must make | What WebCrypto contributes |
|---|---|---|
| Server or database compromise | Store only ciphertext, salts, and public parameters on the server; never store keys or the password | Encryption the server cannot perform without a key it never receives |
| Network interception | Transport security and what the client sends during login and sync | Nothing; transport protection is separate from the Web Crypto API |
| Stolen browser profile | Whether keys persist on disk and in what form | A non-extractable CryptoKey restricts export, but does not stop code in the profile from using the key |
| Cross-site scripting on the vault origin | Assume script can run while the vault is unlocked | Nothing reliable; OWASP notes that a single XSS can read or write IndexedDB |
| Malicious or compromised script or extension | Limit what the vault page loads and what it exposes to other code | Nothing; code running in the page can call the same key operations the vault uses |
| Compromised device while unlocked | Session lifetime, auto-lock, and what stays in memory | Nothing; decrypted data and running code are exposed to the device |
| Maliciously changed application release | Code integrity, signing or verification strategy, and update path | Nothing; the encryption logic is delivered by the same server that the design must not trust fully |
The OWASP HTML5 Security Cheat Sheet is the relevant reference for the browser-side rows, particularly its warnings on profile access and XSS (OWASP HTML5 Security Cheat Sheet).
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Rank #2
- POWERFUL SECURITY KEY: The YubiKey 5C NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5C NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5C NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
Derive the vault key from the master password
WebCrypto’s deriveKey() supports PBKDF2 and HKDF, and the two are not interchangeable. MDN describes PBKDF2 as designed for relatively low-entropy inputs such as passwords, and HKDF as designed for high-entropy input such as an ECDH shared secret (MDN SubtleCrypto deriveKey()). A master password is low-entropy input, so it goes through PBKDF2. HKDF belongs after stretching, not in place of it.
PBKDF2 for the master password
Generate a random salt once per vault, store it in plaintext alongside the ciphertext, and derive the key at each unlock:
const enc = new TextEncoder();
const passwordKey = await crypto.subtle.importKey(
'raw', enc.encode(masterPassword), 'PBKDF2', false, ['deriveKey']);
const vaultKey = await crypto.subtle.deriveKey(
{ name: 'PBKDF2', salt, iterations, hash: 'SHA-256' },
passwordKey,
{ name: 'AES-GCM', length: 256 },
false,
['encrypt', 'decrypt']);The iteration count is the work factor, and it is your decision. The example in MDN’s documentation uses a specific count for illustration; it is not a recommended production value. Choose the count by benchmarking on the slowest device you need to support, record the value in the stored envelope so it can be raised later, and revisit it as hardware changes. Passing false for extractability keeps the derived key non-exportable.
Rank #3
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
HKDF to separate purposes
Once PBKDF2 has produced a derived key, HKDF is the right tool for splitting that key into purpose-specific subkeys, such as one for record encryption and another for any authentication or sync step. This keeps the server-facing authentication material from being the same key that decrypts the vault. Never run HKDF directly on the raw master password.
Encrypt each record with AES-GCM
AES-GCM is the mode to use for this design. MDN’s encrypt documentation explains that GCM is authenticated and checks that the ciphertext has not been modified, while CTR and CBC do not provide authentication by default (MDN SubtleCrypto encrypt()). Without authentication, an attacker who can modify stored records can alter plaintext without detection.
const iv = crypto.getRandomValues(new Uint8Array(12));
const ciphertext = await crypto.subtle.encrypt(
{ name: 'AES-GCM', iv, additionalData: enc.encode(recordId + ':' + version) },
vaultKey,
enc.encode(plaintext));Decryption uses the same algorithm parameters, including the same additional data. If the ciphertext, IV, key, or additional data does not match, the decrypt call rejects, and your code must treat that as a failure rather than falling back to any partial output.
Rank #4
- POWERFUL SECURITY KEY: The Security Key NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key NFC via USB-A and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
The ciphertext envelope
Store each record as a versioned envelope. A practical field list is:
- Format version, so the parser can reject unknown layouts.
- KDF name and parameters (iteration count, hash, and salt), so existing vaults can be re-derived after a change.
- The IV used for that encryption.
- The ciphertext, including the authentication tag that the Web Crypto output carries.
- Record identifier and version number, which are also bound into the additional data.
Binding the record identifier and version into the additional data matters because AES-GCM proves that a record was not altered, but it does not by itself prove that the record is the latest one. An attacker who can write storage could replace a record with an older valid envelope. A version check on read closes that gap, and it also needs to be in the envelope and the authenticated data.
IV uniqueness
Never reuse an IV with the same key. A fresh 96-bit (12-byte) random IV per encryption is the common choice for AES-GCM. Random IVs are only safe while the number of encryptions under one key stays well below the limits published for GCM, so a vault that rewrites records constantly should re-derive or rotate keys rather than encrypt indefinitely under one key. Any alternative IV scheme, such as a counter, must guarantee uniqueness across every device and session that shares the key.
Best Value
- POWERFUL SECURITY KEY: The YubiKey 5 is a versatile physical passkey that protects your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 secures 100+ of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 via USB and tap it to authenticate. No batteries, no internet connection, and no extra fees required.
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
Store keys and ciphertext in IndexedDB
IndexedDB is the browser’s structured persistence option, and MDN identifies it as a typical place to persist CryptoKey objects, which are serializable (MDN SubtleCrypto). Persistence decisions carry real security consequences:
- Persisting a non-extractable key prevents raw key export, but it does not stop JavaScript running on the same origin from calling encrypt or decrypt with that key.
- Anyone with access to the browser profile can read or modify stored data, and OWASP notes that a single XSS can read or write IndexedDB (OWASP HTML5 Security Cheat Sheet).
- Treat every record read back from IndexedDB as untrusted input. Validate the envelope structure, lengths, and version before passing anything to decrypt.
- Deriving the key at unlock and not persisting it shrinks the exposure window, at the cost of asking the user for the master password more often. For most vaults that is the more defensible default.
Recovery: decide it before you ship
Recovery is part of the security design, because every recovery path changes who can regain decryption capability. The OWASP key-management guidance treats the full key lifecycle as a process, not a single feature. There is no single correct recovery design for a vault, so choose one explicitly and document its consequences for users.
| Recovery model | How access is regained | Who gains decryption capability |
|---|---|---|
| No recovery path | A forgotten master password means the data cannot be decrypted | No one other than the user holding the password |
| User-held recovery key | A recovery key is generated at setup and kept offline by the user | Anyone who obtains the recovery key, including someone who finds it |
| Server-held escrow or reset | The server or operator can release or re-wrap access | The server operator and anyone who compromises that server, which breaks the zero-knowledge claim for those vaults |
Do not promise recoverability unless the architecture contains a recovery path that you can state precisely. If the design has no recovery path, say so on the setup screen, before the user creates the master password.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Build sequence
- Serve the application over HTTPS and confirm
window.isSecureContextandcrypto.subtleare available before any vault logic runs. - Write the threat model and answer the boundary questions above. Let those answers decide what the server stores.
- Generate a random salt per vault and benchmark the PBKDF2 iteration count on your target devices. Store the parameters in the envelope.
- Derive the vault key at unlock with extractability disabled. Derive any separate subkeys with HKDF.
- Encrypt each record with AES-GCM, using a fresh random IV and binding the record identifier and version into the additional data.
- Store envelopes in IndexedDB. Persist keys only if the threat model justifies it, and keep them non-extractable.
- On read, validate the envelope, check the version, and decrypt. On any failure, reject the record and do not render partial data.
- Lock the vault after inactivity and drop decrypted values as soon as the view no longer needs them. JavaScript strings and garbage collection do not guarantee that memory is wiped, so state this limit in your documentation.
- Have the design and the implementation reviewed by an independent application security specialist before anyone relies on it for real secrets.
Limits you must state
A WebCrypto vault can be well built and still fall short of the claim it makes. The browser executes whatever code the server delivers, so a compromised release or an injected script can read the master password as it is typed and the plaintext as it is displayed. The server can see metadata that your design leaves visible. And the crypto can only protect data as long as the key and the decrypted state stay out of reach of attackers on the device. Each of these is a boundary your documentation should describe in plain language.
Sources and currency
The MDN and OWASP pages cited in this article describe browser behavior and recommendations as of October 2026. Browser support, the current OWASP guidance, and any MDN revisions to the examples should be checked before you publish a production design, because both the API surface and the recommended parameters change over time.
The Bottom Line
WebCrypto gives you solid primitives for a browser vault: PBKDF2 for the master password, HKDF for purpose separation, and AES-GCM for authenticated record encryption. It does not make a system zero-knowledge. That claim holds only for the boundary you can state and defend: what the server stores, what the delivered code is trusted to do, how persisted keys are exposed, and how recovery works. Keep the claim as narrow as your design, and have an independent review check the whole system before anyone stores real secrets in it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
