Security Model
How W2QR protects your keys — from honey encryption to multi-factor disaster recovery.
No Password Verifier
W2QR never stores a password hash, password-derived MAC, AEAD tag under a password-derived key, known plaintext sentinel, or wallet address. There is no way to check if a password is correct without deriving addresses and checking the blockchain. This is the core guarantee of honey encryption.
Key Lifecycle
- At rest: encrypted in the QR code (honey encryption). In Advanced mode, also requires an authorization secret S.
- During unlock: decrypted in-browser via Argon2id (WASM). Derived keys are zeroized after use.
- During session: signing key held in browser memory for the built-in wallet.
- After timeout: signing key cleared. Re-scan QR to sign again.
The mnemonic exists in memory only during derivation (seconds). At rest, only the encrypted QR exists — there is no plaintext anywhere.
Threat Model
QR stolen (Basic mode)
Honey encryption: every password produces a valid mnemonic. The attacker gets millions of plausible wallets with no way to identify yours. Argon2id (64 MB, 3 iterations) makes each attempt slow.
QR stolen (Advanced mode)
The attacker also needs the authorization secret S (from your device, Google account, or Recovery Code). Without S, decryption still produces valid-looking mnemonics — but wrong ones. QR + password alone is not enough.
Share stolen (Shamir Shares mode)
A single share reveals zero information about the mnemonic — this is an information-theoretic guarantee. The attacker needs M shares AND each share's password. Even with fast brute-forcing, the search space is P^M (exponentially harder than attacking a single QR).
Brute-force attack
No oracle: the attacker cannot tell when they've guessed correctly. They must check each candidate mnemonic against the blockchain — infeasible at scale.
Server compromised (Advanced mode)
The server stores only KEK-wrapped S and R1 share, linked to a hashed Google subject ID. Without your password (which the server never receives), S is useless. R1 alone cannot reconstruct the recovery root — 2 of 3 shares are needed.
Google Account compromised
A compromised Google Account can release the wrapped S and R1 share, but these are encrypted under the server KEK. Even with both, the attacker needs your password to decrypt. Google never receives your password, mnemonic, or private keys. Google Drive backups are also ciphertext only.
Device lost or reset
WebAuthn credentials and the device-bound S are lost, but you can recover using Google Account + Recovery Code (R1 + R3). Re-enroll a new device after recovery.
Browser compromised
During unlock, the mnemonic exists briefly in browser memory. A fully compromised browser can intercept it. This is the same threat model as typing a password on any web page. Use a clean browser profile.
Man-in-the-middle
All cryptography runs client-side in the browser. The encrypted payload never transits the network in cleartext. API routes that release secrets use rate limiting, IP throttling, and response timing normalization.
Trust Domains
| Domain | Knows | Cannot access |
|---|---|---|
| You | Password, Recovery Code, QR | Server KEK |
| Google Account / W2QR server | Wrapped S, R1, encrypted backup | Password, mnemonic, private keys |
| Your device | PRF-encrypted S, R2 share | Server data, Recovery Code |
| QR thief | Ciphertext only | Password, S, all shares |
| Share thief (Shamir) | One encrypted share | M-1 other shares, all passwords |
No single trust domain can access your wallet. Even a full compromise of Google Account + the W2QR server yields only encrypted data and one share — not enough to recover your seed phrase.
Hardware Wallets vs W2QR
Hardware wallets and W2QR solve the same problem — keeping your seed phrase safe — but with fundamentally different trade-offs.
| Property | Ledger / Trezor | W2QR |
|---|---|---|
| Key at rest | Secure element (hardware) | Honey-encrypted QR (paper/file) |
| Key exposure | Never leaves secure element | In-browser during derivation (zeroized after) |
| Brute-force resistance | PIN lockout (3-10 attempts) | Honey encryption: no oracle, every password valid |
| Forgotten PIN / password | Must use paper seed backup | Advanced: 2-of-3 disaster recovery |
| Physical theft | PIN protects; wipe after 3 failures — but thief has the device | QR alone is useless (needs password + factor) |
| Backup strategy | Seed on paper — the exact secret in plain text | QR is already encrypted — safe to store digitally or print |
| Supply chain risk | Tampered device can leak keys (Ledger 2023 incident) | No hardware: code is open and runs in your browser |
| Firmware updates | Vendor pushes firmware — must trust the update won't extract keys | Client-side only: no firmware, no forced updates |
| Physical damage / loss | Broken or lost device = buy new one, re-enter seed from paper | QR is copyable: print multiple copies, cloud backup |
| Device availability | Must carry the device; can't sign without it | Any browser, any device — scan and go |
| Vendor dependency | Vendor discontinues model = migration headache | Standard BIP-39 — import seed into any wallet |
| Blind signing risk | Small screen often shows hex, not human-readable tx details | Browser shows full transaction details |
| Cost | $60–200+ per device | Free |
The honest trade-off
A hardware wallet's secure element ensures the private key never enters the host computer's memory. W2QR cannot match this guarantee — during the unlock step, the mnemonic briefly exists in browser memory (derived keys are zeroized after use). This is the trade-off for not requiring a physical device.
However, every hardware wallet owner also has a paper seed phrase backup — that backup has zero encryption. If someone finds that paper, they have your wallet. W2QR replaces the unprotected paper backup with honey-encrypted data that is safe even if stolen.