A browser profile's saved logins and cookie store are copied to another machine — why are they inert?
answer
- ciphertext plus a wrapped key
- who satisfies the unwrap condition
- master key under the user SID
- derived from the logon password
- domain controllers hold a backup key
basics
~20 sThe profile's secrets are sealed with a per-profile key that Windows DPAPI protects, and the DPAPI master key behind it is derived from the user's own logon password. Copied alone, the files decrypt to nothing.
solid answer
~50 sBrowser profiles do not store passwords or cookie values in the clear on Windows or macOS. A per-profile symmetric key sits beside the profile, itself wrapped by the platform secret store — DPAPI on Windows, the login keychain on macOS. DPAPI wraps it with the user's master key, held under `%APPDATA%\Microsoft\Protect\<SID>\` and derived from the user's logon password; for a domain account, a second copy is protected by a domain-wide backup key that domain controllers hold. So the copied folder is useful only with one of: code running as that user on that host, where the operating system unwraps everything transparently; the user's password or password-derived material plus the master key file; or that domain backup key. This is why in-context theft beats offline copying, and why the folder alone is the middle tier of the on-disk ranking — not free, not hopeless.
go deeper
Know that the browser does not keep saved logins or cookies in the clear on Windows or macOS, and that the protecting key is tied to the signed-in user rather than to the file itself.
Walk the chain out loud: profile secret, per-profile key, DPAPI master key under the user's SID, password-derived unwrap, domain backup key. Then name the three ways an attacker satisfies that chain.
Demonstrate the reframing from "is it encrypted" to "what condition unwraps it, and who meets that condition", and use it to explain why code running as the user is the cheap path.
Be able to argue where protection investment belongs: narrowing unwrap conditions and shortening credential lifetime, rather than adding encryption layers whose keys are reachable from the same context as the data.
## The chain, top to bottom A browser profile on Windows holds saved logins and a cookie store in local database files. The values inside are encrypted with a **per-profile symmetric key**, and that key is stored — wrapped — in a small state file alongside the profile. The wrapping is done by the platform's data-protection service. On Windows that service is **DPAPI** (the Data Protection API). It exposes two calls, protect and unprotect, and it hides all key management. Under the hood: 1. Ciphertext produced by DPAPI carries the GUID of the **master key** used. 2. Master keys live in per-user files under `%APPDATA%\Microsoft\Protect\<user SID>\`, named by that GUID. 3. A master key file is itself encrypted with a key derived from the **user's logon password** (via the password-derived hash), plus, for a domain account, a second blob protected by the **domain backup key** held by domain controllers. 4. A `CREDHIST` chain lets older master keys still be opened after the user changes their own password. On macOS the equivalent is the **login keychain**, unlocked by the login password at sign-in. On Linux the browser typically defers to the desktop keyring, and where none exists it falls back to a fixed key — which is exactly why a Linux profile is often far weaker than its Windows counterpart. ## Why the copied folder is inert The folder contains ciphertext and a wrapped key. It does not contain the master key's unwrap secret. Move it to another machine and there is nothing to unwrap with — the master key file may even have been copied too, but the thing that opens *it* is the user's password-derived material, not something in the folder. That gives three, and only three, realistic ways in: - **Be the user, on that machine.** Code running under the user's token calls unprotect and the operating system does the whole chain silently. This is the cheapest path by a wide margin and it is why a signed-in insider pays nothing for this tier. - **Have the password, or the password-derived hash, plus the master key file.** Offline, this reconstructs the chain. - **Have the domain backup key.** A domain controller can open any domain user's master key. This exists so an administrative password reset — which breaks the `CREDHIST` chain — does not destroy the user's protected data. ## The distinction that matters in an interview "Is it encrypted?" is the wrong question. The question is **what condition unwraps it, and who can satisfy that condition.** DPAPI's condition is "be this user, in this user's session, on a machine that can reach the key material". Against a thief with the disk and no password, that is a real barrier. Against the user themselves, or anything running as them, it is not a barrier at all — it is a convenience layer that the operating system removes on their behalf. This is the same reasoning that makes "encrypt the credential file" a weak answer generally: if the reader that needs it can decrypt it, so can anything with the reader's context. ## What actually raises the cost Recent Windows browser builds bind the profile key more tightly than plain user-scoped DPAPI, requiring the browser's own executable identity (established with help from a privileged service) rather than merely the user's session, so a copied folder plus the user's password is no longer sufficient and arbitrary code running as the user has more work to do. That is a genuine increase in cost, not an elimination — but it shows the direction that helps: narrow the unwrap condition from "this user" to "this program, on this machine". The stronger version of the same idea is **non-exportable** material: a key held in a TPM or a hardware security key that can be used for an authentication and never read out. Nothing in the profile folder has that property; a cookie, once unwrapped, is bearer material that works anywhere until it expires or the server invalidates the session. ## Summary The copied folder is not the secret. It is ciphertext plus a wrapped key whose unwrap condition is the user's own logon secret, satisfied for free inside their session, satisfiable offline with their password and master key file, and satisfiable centrally with the domain backup key.
- An administrator resets a domain user's password — why is the user's protected data still recoverable?A user-initiated password change re-wraps the master key and records the old one in the `CREDHIST` chain. An administrative reset does not, so that chain breaks. Recovery comes from the second copy of the master key, protected by the domain backup key held by domain controllers, which can open any domain user's master keys regardless of password history.
- Why is theft from inside the user's session so much cheaper than theft of the folder?Inside the session the operating system performs the whole unwrap on request: the caller asks DPAPI to unprotect and gets plaintext, with no password, no master key file parsing and no cracking. Offline, the same result requires the master key file plus the user's password-derived material. Same secret, wildly different cost.
- Does encrypting the cookie store with a stronger cipher help?Almost not at all. The weakness is never the cipher, it is the reachability of the unwrap condition. Strengthening protection means narrowing who can satisfy it — binding to a specific program or to hardware that will use a key but never export it — or shortening the lifetime of what the unwrap yields.
saying these in an interview costs you the question
- Says browser profiles store passwords in plain text on Windows
- Thinks copying the profile folder is enough to read the cookies
- Believes DPAPI keys are held by the TPM rather than password-derived
- Cannot name what unwraps the master key
- Assumes a stronger cipher would fix it