Browser Password Managers vs Bitwarden on Windows: DPAPI, Windows Hello and Malware Risks

The case against the browser vault​

Phillips makes a few main points:

• Browsers keep secrets in the profile folder. Saved credentials sit locally and can sync through Google, Microsoft or Apple accounts.
• Encryption depends on the operating system. On Windows that means DPAPI. In his account it unlocks automatically when you sign in, so anyone using your session, or any malware running in it, gets the same access.
• Dedicated managers add their own lock. Their vaults are encrypted with a master password or key that you control, and the provider says it can't read them.
• Dedicated managers offer more tools. He cites deeper audits, breach alerts, reuse detection, emergency access and recovery options.

For people who won't switch, he suggests 2FA, Chrome's on-device encryption, locking down the device, keeping your most sensitive passwords out of the browser, and checking your saved list regularly.

What DPAPI actually protects against​

The central technical claim is the strongest part of the piece. Microsoft's own documentation for CryptProtectData says that data protected this way can usually be decrypted only by a user with the same logon credentials, and usually only on the same computer. That is real protection against other accounts on the PC and against someone who pulls the drive. It does nothing against code that runs as you.

Google said the same thing about its own browser. When Chrome engineer Will Harris announced a stronger scheme, he explained that DPAPI protects the data at rest from other users on the system or cold boot attacks, but does not protect against malicious applications able to execute code as the logged-in user – which infostealers take advantage of.

So in plain terms: if an infostealer runs in your Windows session, the browser's OS-level lock isn't much of a lock.

Chrome's app-bound encryption​

The MakeUseOf piece leaves this out. Google responded to the infostealer problem with app-bound encryption on Windows. It uses a Windows service running under SYSTEM privileges to confirm an app's identity when it requests encryption, encodes that identity into the encrypted data, and ensures only the intended app can decrypt it. Google started with cookies in Chrome 127 and said in future releases it intended to expand this protection to passwords, payment data, and other persistent authentication tokens.

It isn't foolproof. Within months, BleepingComputer reported that infostealer malware developers released updates claiming to bypass the feature. Elastic Security Labs listed the techniques: remote debugging via Chrome's DevTools Protocol, reading process memory of Chrome's network service process, and elevating to SYSTEM to decrypt the app-bound key through COM. Google raised the cost of attack, and attackers paid it. That's how these things usually go.

Section summary: The criticism that DPAPI doesn't stop same-user malware is accurate and confirmed by Microsoft and Google. Chrome has since added a second layer on Windows, but that layer has been bypassed in practice.

Where the "stop now" argument goes too far​

The headline is stronger than the evidence. Some corrections:

1. Dedicated managers don't beat malware on your PC either. A vault encrypted with a master password is strong at rest and on the provider's servers. Once you unlock it to autofill, though, it's running on the same compromised machine. The MakeUseOf table implies malware can't get into a dedicated vault, and nothing in the evidence supports that. Client-side encryption mainly protects you when someone steals the vault data from the provider's servers.
2. Browsers do have auditing tools. Microsoft's support documentation says Edge's Password Monitor checks saved credentials against a large database of known leaked credentials, and syncing users get it switched on automatically. Google's Chrome Help describes a Checkup page that flags exposed and weak passwords.
3. "The browser" isn't one setup. According to Google, Chrome can save passwords to your Google Account when you're signed in, or only on the device when you're not. It also offers separate on-device encryption.
4. Edge now requires device authentication. Microsoft's support page says Edge's Custom Primary Password stopped being available to new users on March 5, 2026, and was due to be removed for remaining users on June 4, 2026. After that, saved passwords are protected by device authentication such as Windows Hello or your device password. Microsoft says enterprise admins will see the related policy marked obsolete.
5. 2FA helps, but with a different problem. It protects against someone signing in with a stolen password. It doesn't encrypt your profile folder and it won't stop someone sitting at your unlocked PC. Session cookie theft, as the app-bound saga shows, can get around it entirely.

My own view, based on general industry practice rather than any one source: the bigger risks are reused passwords and an unpatched, malware-friendly PC. A strong, unique password saved in Edge is much safer than "Summer2019!" used on 40 sites and stored in the best vault money can buy.

If you stay in the browser: harden it​

Microsoft Edge (Windows 11/10), steps from Microsoft's support pages:

1. Go to Settings > Passwords and autofill > Microsoft Password Manager > More settings.
2. Make sure Autofill passwords and passkeys is on.
3. Choose Prompt for the device sign-in options before viewing or filling website password, then confirm with Windows Hello or your device credentials.
4. In the same area, turn on Scan passwords for leaks. Results appear under Password security check.

Google Chrome, from Google's Chrome Help:

1. Open the More menu and go to Passwords and autofill > Google Password Manager > Settings.
2. Turn on Use Windows Hello when filling passwords. Google notes that biometric authentication is off by default.
3. Go to Checkup to see exposed and weak passwords.

Then do the basics: keep the browser and Windows updated, use a strong Windows sign-in, and change every password a checkup flags.

If you switch: migrate without leaving a mess​

Google's export steps are: More > Passwords and autofill > Google Password Manager > Settings, scroll to Export passwords, and select Download file. MakeUseOf describes the same route through the profile icon or chrome://password-manager, and says Chrome will ask for your Windows credentials before it writes the CSV.

Watch out: that CSV contains every password in plain text. Google warns that if you don't delete it, anyone who uses the device can open it and read your passwords. A safe routine:

1. Export only on a PC you trust that's free of malware.
2. Import into your new manager straight away.
3. Test a few logins, including at least one important account.
4. Delete the CSV and empty the Recycle Bin. My own advice: check that it didn't get copied to OneDrive or a backup folder.
5. Once you're sure the migration worked, turn off saving and delete the old browser entries so you aren't running two vaults.

If you're moving into Chrome instead, Google says it takes CSV files of up to 3,000 passwords per import, with a limit of 10,000 passwords per Google Account. Site names don't always land in the right field.

The verdict​

You don't have to treat browser password storage as an emergency. The real question is whether a separate lock on your passwords is worth an extra master password and another app. You can trust the browser vault less if:

• you share a Windows account,
• you install software from questionable sources, or
• you handle work credentials an infostealer would love to sell.

In those cases a dedicated manager's separate encryption is worth having. For everyone else, a browser that requires Windows Hello before autofill and runs leak scans, combined with unique passwords, beats a hastily migrated vault every time.

Neither option fixes a compromised PC, though, so keep patching and stay careful about what you download.