DEV Community

Claudia
Claudia

Posted on

How Chrome, Edge, and Brave Store (and Leak) Your Saved Credentials

How Chrome, Edge, and Brave Store (and Leak) Your Saved Credentials

Every time you hit "Save Password" in your browser, that credential gets written to a SQLite database on your local machine. It's encrypted — but not as securely as most people think.

This article is a technical walkthrough of the Chromium credential storage architecture. Understanding this is crucial for anyone doing Windows security research, red teaming, or building pentesting tooling.

The Storage Architecture

Chromium-based browsers (Chrome, Edge, Brave, Opera, Vivaldi) all share the same credential storage pipeline. There are two key files:

1. Local State — The Master Key

Located at:

%LOCALAPPDATA%\Google\Chrome\User Data\Local State
Enter fullscreen mode Exit fullscreen mode

This is a JSON file containing browser-level configuration. The critical field is os_crypt.encrypted_key — an AES-256-GCM key that's itself wrapped using Windows DPAPI (CryptProtectData).

When Chrome starts, it:

  1. Reads Local State
  2. Extracts the encrypted_key (base64-decoded, first 5 bytes stripped — those are a version prefix "DPAPI")
  3. Calls CryptUnprotectData to unwrap it using the current Windows user's DPAPI credentials
  4. The result is a 256-bit master key used for all subsequent encryption/decryption

2. Login Data — The Credential Store

Located at:

%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data
Enter fullscreen mode Exit fullscreen mode

This is a SQLite database with a logins table containing:

  • origin_url — the website the credential is for
  • username_value — the saved username (plaintext)
  • password_value — the encrypted password (BLOB)
  • date_created, date_last_used, etc.

The password_value BLOB is encrypted using the master key from Local State with AES-256-GCM. The encrypted format is:

Version (1 byte) | Nonce (12 bytes) | Ciphertext | Authentication Tag (16 bytes)
Enter fullscreen mode Exit fullscreen mode

The Encryption Flow

User hits "Save Password"
         ↓
Browser generates: Nonce (random 12 bytes)
         ↓
Encrypts password bytes with: AES-256-GCM(master_key, nonce, plaintext)
         ↓
Writes to Login Data: version + nonce + ciphertext + tag
Enter fullscreen mode Exit fullscreen mode

The Decryption Flow (For Research Purposes)

On the same machine, as the same Windows user, the process to read these credentials:

1. Read Local State → extract encrypted_key
2. CryptUnprotectData(encrypted_key) → master_key (256-bit)
3. Read Login Data → extract password_value BLOB
4. Parse: [1 byte version][12 bytes nonce][ciphertext][16 bytes auth tag]
5. AES-256-GCM decrypt(master_key, nonce, ciphertext, tag) → plaintext password
Enter fullscreen mode Exit fullscreen mode

In C++, this requires linking against Crypt32.lib for DPAPI and a crypto library (or Windows BCrypt) for AES-GCM.

Beyond Passwords: What Else Is There?

The same master key decrypts the entire Chromium credential ecosystem:

File Contents
Login Data Saved usernames + encrypted passwords
Cookies Session cookies (encrypted_value BLOBs)
Web Data Autofill profiles + credit card numbers
Current Session Active browser tabs + navigation state
Current Tabs Restored tab data

The key insight: one master key unlocks all of it.

The Real Security Concern

The master key is decrypted via DPAPI, which means any process running as the same Windows user can request it. There's no additional authentication, no TPM binding (on most systems), and no user prompt.

This is by design — so Chrome can autofill passwords seamlessly. But it also means that if an attacker gains code execution at the user level, the entire credential store is accessible.

Extraction tools simply:

  1. Check for presence of Login Data / Cookies / Web Data files
  2. Read Local State and decrypt the master key via DPAPI
  3. Walk each database and decrypt every BLOB

The operation is silent. No popups. No warnings.

How Automated Platforms Handle This

Full-spectrum credential extraction at scale requires:

  • Reliable detection of Chromium profiles across Chrome, Edge, Brave
  • SQLite parsing with proper lock handling (browsers lock these files while running)
  • AES-256-GCM decryption with correct nonce parsing
  • DPAPI local state unwrapping
  • Organized output with per-domain grouping

Platforms like V-Entity handle the entire pipeline — from agent deployment on a Windows target to credential decryption, cookie extraction, and browser session hijack — all through a single web dashboard. Every agent is compiled per-deployment for unique signatures, with per-system configuration for target paths, sharing intervals, and data exfiltration.


This article is for educational purposes. Understanding browser security architecture helps researchers build better defensive tools. Always work within authorized testing boundaries.

Top comments (0)