browserforensics
Back to all articles

Decrypt saved passwords and credit cards (Chrome & Edge)

2026-06-21 · 3 min

Cookies are not the only thing Chromium encrypts with the per-profile os_crypt key. The same AES-256 key protects saved passwords in Login Data and saved card numbers in Web Data. Once you have unwrapped that one key — the same DPAPI chain used for cookies — you can read all three artifacts in a single pass, offline, with nothing leaving the tab.

One key, three artifacts

Chromium stores one AES-256 os_crypt key per profile in Local State. Every encrypted field — cookie values, passwords, card numbers — is the same self-describing blob: a v10/v20 version tag, a 12-byte AES-GCM nonce, ciphertext, and a 16-byte GCM tag. Decrypt one and you can decrypt all of them.

ArtifactDatabaseEncrypted columnCleartext context
Saved passwordsLogin Datalogins.password_valueorigin_url, username_value
Saved cardsWeb Datacredit_cards.card_number_encryptedname_on_card, expiration_month/year
CookiesCookies (Network)cookies.encrypted_valuehost_key, name

The username, the origin URL, the card holder and expiry are all stored in plaintext — only the secret itself (password_value, card_number_encrypted) is wrapped. That means even before decryption you can see which accounts and cards exist; the key recovers the values.

What to collect

From the target profile and host:

InputWhere it lives
Cookies…\User Data\<Profile>\Network\Cookies
Login Data…\User Data\<Profile>\Login Data
Web Data…\User Data\<Profile>\Web Data
Local State…\User Data\Local State
DPAPI masterkey%APPDATA%\Microsoft\Protect\<SID>\<GUID>
User SID + NT hash or passwordSID is the \Protect\ folder name; NT hash from SAM

You do not need all three databases — load whichever ones the case calls for. Local State plus the key inputs are what unlock them.

Workflow

  1. Load the databases. Drop Cookies, Login Data and Web Data onto the same drop zone — uploads accumulate, so all three stay loaded. Each table appears with an empty Decrypted value column.
  2. Add Local State (and the masterkey file). The masterkey GUID the tool reports must match a file under …\Protect\<SID>\.
  3. Provide the key. Either paste an already-unwrapped 32-byte os_crypt key (hex or base64), or run the offline DPAPI derivation here: enter the SID and choose NT hash or password.
  4. Derive key & decrypt. The tool unwraps the masterkey (verifying its HMAC), unwraps the AES key, and fills the Decrypted value column across all loaded tables in one pass — passwords, cards and cookies together.

If the SID or secret is wrong, the masterkey HMAC fails with a clear error rather than producing silent garbage in any of the three tables.

Reading the results

  • Passwords (Login Data deep-dive) decrypt next to origin_url and username_value — a credential set ready to pivot on.
  • Card numbers (Web Data deep-dive) decrypt next to the cardholder name and expiry. Handle these per your jurisdiction's PCI/PII rules.
  • Each table exports to CSV or JSON independently.

Scope and limits

  • v10 fields decrypt fully with this flow on Windows. v20 (app-bound, Chrome 127+) is a separate, experimental path — the app-bound key does not fully reduce to offline math yet (why).
  • Edge is Chromium — the same os_crypt scheme and the same key derivation apply, just under the Edge User Data path.
  • macOS / Linux use a different key source (Keychain Chrome Safe Storage, or the GNOME Keyring / KWallet secret). The decrypt step is identical once you hold the key.
  • Don't forget the -wal sidecar next to each database — drop it too so recently-added passwords or cards aren't missed.

Further reading