Microsoft Edge: Why Browser Cleartext Passwords Linger in Memory

## The 'Airtight Hatchway' Fallacy: Why Browser Memory Isn't as Secure as You Think

It's a common frustration in cybersecurity: you find a clear security gap, report it, and get a "wont fix" response. That's exactly what happened when CyberArk researcher Zeev Ben Porat discovered in June 2022 that major web browsers, including Microsoft Edge, Google Chrome, and Firefox, store sensitive data like **browser cleartext passwords** and session cookies in memory. Even when those passwords aren't actively being used, they can sit there for the browser's entire runtime. You can read Ben Porat's full research on the CyberArk blog.

The official stance from vendors like Google/Chromium? This falls outside their threat model. If an attacker has local access to your machine, especially administrative access, they consider it "game over" anyway. I've heard this argument countless times, and while it has a certain logical consistency, it misses a critical point about defense-in-depth.

How Your Browser Keeps Secrets in Plain Sight: The Issue of Browser Cleartext Passwords

Here's what actually happens: when you log into a site or when your browser loads saved credentials, those passwords are decrypted from their on-disk storage (which, for Edge, uses OS-level mechanisms like DPAPI) and loaded into volatile memory. The problem isn't that they're decrypted at the moment of use – that's necessary. The problem is these **browser cleartext passwords** often stay decrypted in memory, accessible, long after that active use.

Zeev Ben Porat's research showed that an attacker doesn't necessarily need physical access. Remote access or even just running a non-elevated process on the same machine can be enough. This process could extract:

1. Usernames and passwords used for active sign-ins.
2. Credentials automatically loaded at browser startup.
3. All URL, username, and password records stored in the browser's Login Data.
4. Session cookies, which can be used for session hijacking.

And this isn't just an Edge thing. It's a behavior common across most major browsers, including Chrome, Brave, and Firefox (unless you've set up a master passphrase, which isn't the default).

The "Game Over" Argument vs. Reality: Why Browser Cleartext Passwords Matter

The browser vendors' argument, often called the "Airtight Hatchway" fallacy in security circles, goes like this: if an attacker has administrative access to your machine, they have total control. They can attach a debugger to any process, dump memory, and bypass application-level protections. Therefore, protecting in-memory **browser cleartext passwords** against such an attacker is futile and outside the browser's responsibility. Google's "wont fix" response to Ben Porat's report reflects this exact philosophy.

I understand the logic. If an attacker owns the OS, they own everything on it. But that's a very narrow view of the threat landscape.

Here's why it still matters:

• Lower Privilege Attacks: A standard user on Windows can often read arbitrary process memory for non-admin processes. An "evil process" running under the same user context as the browser might be able to get PROCESS_VM_READ permissions, change page protection, or inject code to access browser memory. You don't always need full system compromise.
• Browser Exploits: Many browser-specific vulnerabilities, especially in Chromium, involve massaging memory structures to read or write specific bytes. If **browser cleartext passwords** are sitting there, a successful exploit that grants memory read capabilities (even without full user compromise) can easily grab them.
• Unattended Devices: An unlocked, unattended computer is a prime target. An attacker could quickly dump all saved passwords from browser memory.
• OS Swap File: This is a big one. **Browser cleartext passwords** stored in memory can be written to the operating system's swap file on disk when physical RAM runs low. If that disk image or physical drive is later compromised, those passwords are no longer just "in memory"; they're on disk, unencrypted.
• Lateral Movement: Compromised plaintext credentials are gold for an attacker looking to move laterally within an organization. They can use these to access other systems, services, or even for phishing campaigns.

The social sentiment around this is mixed, as you'd expect. On platforms like Hacker News, you see people agreeing with the "game over" argument, saying if an attacker has admin access, it's pointless. But there's also a strong undercurrent of skepticism, a call for better defense-in-depth. People point out that "unused" passwords shouldn't just sit there, especially since the password database is often open for much of the browser's lifetime. It's not an Edge-specific flaw, but it's still a design choice that leaves a door open.

What We Should Be Doing About It: Mitigating Browser Cleartext Passwords Risk

Browser vendors, including Microsoft, do rely on OS-level protections. Edge uses DPAPI, and if LSASS isolation is enabled (which is default on Windows 11 physical machines), even SYSTEM privilege might not grant direct access to credentials. That's good. But it's not enough.

Here's what I think needs to change:

• Memory Wiping: This is non-negotiable. Credentials should be wiped from memory as soon as they're no longer actively needed. Windows provides SecureZeroMemory and other primitives to prevent compiler optimizations from removing these wipes. It's "bad style" to keep decrypted secrets lying around.
• Guard Pages: Placing secrets between guard pages is a standard defense-in-depth technique. It makes them readable only when explicitly accessed, causing a segfault on inadvertent access. It's not a silver bullet, but it's another layer.
• Hardware Isolation: Moving towards hardware-isolated environments like Trusted Execution Environments (TEEs) or TPMs to store and manage sensitive data is the right long-term direction. Yes, it introduces usability challenges with device dependency and recovery, but the security gains are significant. Passkeys, which Google is actively pushing, are a step in this direction, binding credentials to devices via TPMs.
• Dedicated Password Managers: For users, this is a practical mitigation today. External password managers like Bitwarden or KeePass often have better in-memory protection or require re-authentication (e.g., a master password or biometrics) after inactivity.

The "wont fix" stance from browser vendors, while technically consistent with their defined threat model, creates an unnecessary gap in the overall security posture. It's a classic example of focusing on the perimeter while leaving the interior vulnerable. We need to move beyond the idea that "if they're in, they're in" and embrace a more granular, defense-in-depth approach to memory hygiene. Keeping **browser cleartext passwords** in memory, even when "unused," is a risk that we can and should mitigate.