How do popular web browsers (chromium/blink, firefox/gecko) store passwords, do they encrypt the stores locally, and how?
Executive summary
Chromium-based browsers store passwords in a local SQLite database and encrypt those password blobs with symmetric AES keys whose protection depends on the operating system’s secret stores (Windows DPAPI, macOS Keychain, Linux keyrings) or on per-user encryption schemes like Chromium OS’s TPM-backed vault; this design means stored passwords are encrypted at rest but often decryptable by processes running as the logged-in user [1] [2] [3]. Reporting supplied here contains detailed, corroborated descriptions for Chromium-family behavior but does not include authoritative documentation for Firefox/Gecko, so claims about Firefox’s mechanisms cannot be confirmed from the provided sources.
1. How Chromium-family browsers keep credentials: file + key separation
Chromium stores saved credentials in a local SQLite file called “Login Data” (the browser profile) and keeps the encryption key or “master key” in an OS-specific place rather than in the same database file; on Windows that key is wrapped with the OS Data Protection API (DPAPI) and on macOS it is placed in the system keychain, while on Linux Chromium delegates to GNOME Keyring, KWallet or a built‑in “basic” store depending on environment [1] [2] [4] [5].
2. What encryption is used and who can decrypt it locally
Chromium encrypts password values with symmetric AES (variations reported include AES-128-CBC on some platforms and AES-256 on Windows for other sensitive data) and derives the AES key via PBKDF2 or platform-wrapping before storage in Local State or the OS vault; because the decryption key is ultimately protected by an OS facility accessible to processes running as the same user, local malware or user-mode tools can often recover plaintext if they run in the user session [2] [6] [7].
3. Linux nuance: keyrings, fallbacks and the unencrypted trap
On Linux, Chromium’s behavior varies by desktop environment: when GNOME Keyring or KWallet is present Chromium will move unencrypted passwords into those encrypted stores, otherwise it may store the SQLite password blobs without additional OS-wrapped encryption (the “basic” store), meaning encryption at rest can be absent if no keyring is available [5] [8] [9]. Chromium’s own docs and community reporting explicitly warn that without a functioning keyring the stored data may not be encrypted [4] [5].
4. Chromium OS and stronger hardware-backed protections
Chromium OS implements per-user encrypted “vaults” whose keysets are tied to login credentials and, when available, the platform TPM is used to protect the vault keyset against offline brute-force attacks; Chromium OS uses scrypt (or TPM-backed secrets) to bind the vault keyset to the user’s password hash and unlocks the encrypted keyset at login [3]. This design illustrates a stronger threat model—hardware-backed key protection—compared with the typical desktop Chromium approach that relies on the OS user-session protections [3].
5. Security tradeoffs, real-world attacks and vendor messaging
Security researchers and proof-of-concept tooling show that the practical effect of Chromium’s design is that local user-mode code can often extract and decrypt App-Bound or profile secrets if it can run in the same user context, and attackers have developed techniques (DLL injection, process compromise) to leverage the browser’s own decryption facilities to harvest cookies, passwords and payment data [10] [11]. Vendors emphasize encryption at rest and platform integration—Chrome’s use of scrypt for password fingerprinting and OS-wrapped keys is an example of that messaging—but the implicit agenda is to reduce attacker risk while preserving usability; critics point out that tying keys to user-session secrets still leaves decryption available to any code the user’s account already trusts [12] [2].
6. What’s missing from the record: Firefox/Gecko specifics
The supplied reporting does not include authoritative, source-cited documentation about Firefox/Gecko password storage, encryption algorithms or where Firefox stores its master keys, so no definitive statements about Firefox’s implementation can be made from these sources; independent verification against Mozilla’s documentation would be required to compare architectures fairly (no source).