Keep the conclusion in one place. AES-256-GCM answers whether the password field in the on-disk store is plaintext. It does not answer who is allowed to unwrap the key. On 30 July 2024 Google wrote that Windows DPAPI blocks other users on the system and cold-boot attacks, and that it does not block a program able to run as the logged-in user. Starting in Chrome 127, app-bound encryption moved cookies from “this user” to “this browser application.” Neither door means “no program on this machine can read the secret.”
What the search is actually asking
People who search “are Chrome saved passwords encrypted, so malware cannot see them” are usually asking one thing: after I clicked Save, can another program on this computer still recover the plaintext? The cipher name does not settle that. In the Google security blog, Will Harris of the Chrome security team described the older Windows boundary in plain terms. Chrome protects sensitive data such as cookies and passwords with the strongest facility the operating system offers. On Windows that facility is the Data Protection API (DPAPI). It protects data at rest from other users on the system and from cold-boot attacks. A malicious application that can execute code as the logged-in user sits outside that protection, and that is the gap infostealers use.
This note is for two readers. One is a developer or operator reviewing a sentence like “the browser already encrypts saved passwords, so we do not have to think about passwords on disk.” The other saw a security write-up this week and wants to know what the word “encrypted” on a settings page actually proves. It does not explain how to unwrap someone else’s password store, and it is not a substitute for the password generator page. Take away three facts you can separate: what ciphertext proves, what key wrapping proves, and what the 25 September 2026 report does not prove.
AES-256-GCM only shows the field is not plaintext
Chromium-based browsers keep saved logins in the local profile. On newer builds the password field is sealed with AES-256-GCM. Open that store in a text editor and you will not see the site password in the clear. That part is real. GCM also means a flipped byte fails the authentication check, so the ciphertext is not a plaintext string you can quietly edit in place.
The browser still has to fill the password the next time the login form appears, so the key cannot live only in a passphrase that you alone remember. After the session is unlocked, the browser on this machine has to be able to use it. The useful question therefore moves from “is the algorithm strong?” to “who is allowed to ask the system for this key?” A strong cipher does not move the door. If the right to unwrap sits with “the Windows user who is already logged in,” a program started as that user stands on the same side of the door as the browser.
That is why the same algorithm name is a different sentence from “local encryption under a passphrase you type.” When you encrypt a file in the browser with AES-256-GCM and a passphrase you hold, another program and a cloud drive do not have that passphrase by default, so they cannot open the file. A browser password store is built for autofill. The right to use the key has to remain with the browser on this machine. Seeing AES-256-GCM in both places does not make the two key arrangements the same arrangement.
The boundary Google already wrote down
The same 30 July 2024 note spells out the operating-system split. macOS uses Keychain services. Linux uses a system wallet such as kwallet or gnome-libsecret. Windows uses DPAPI. The sentence about “a program running as the logged-in user” is Google’s description of Windows DPAPI. Do not paste it onto every Mac. Keychain can raise a system confirmation. That interaction is a different door from “any process of this user unwraps the secret with no prompt.”
On Windows, DPAPI ties protection to that user’s logon. Google’s stated cases are other users on the system, and cold-boot attacks. That is the half of “it is encrypted” that holds up in a product review. Google states the other half directly: DPAPI does not protect against a malicious application able to execute code as the logged-in user. That program can ask the operating system through the same kind of interface the browser uses. The cipher has not failed. The door was drawn around other users and cold-boot attacks, not around other processes of this user.
When a review says “the password store uses AES-256-GCM, therefore local malware cannot read it,” split the sentence. The first half can be supported by opening the store and seeing that the password field is not plaintext. On the DPAPI generation, the second half contradicts Google’s public note. The evidence you still need is whether this browser has moved this class of secret to the next door. The algorithm name is not that evidence.
Chrome 127 moves the door from the user toward the app
The same note continues: Chrome 127 introduces app-bound encryption on Windows. The data is no longer available to any app running as the logged-in user. Chrome encrypts it tied to application identity, and a system-side component checks that the caller is a trusted browser before it releases the key. Google’s migration order is explicit. Cookies move first, in Chrome 127. Passwords, payment data, and other persistent authentication tokens are secrets the team intended to expand to in later releases. They were not described as fully migrated on the day 127 shipped.
By early 2026, public forensic descriptions still draw that line. ElcomSoft’s January 2026 note says app-bound encryption began with cookies, with an architecture meant to extend to passwords and payment data, and that Microsoft Edge followed because it shares the Chromium core. On profiles where the new wrapping is actually in use, a third-party program running as the user fails when it asks the operating system the old way: the caller is not the verified browser executable. That door blocks an ordinary process standing outside the browser. It does not block the inside of the browser process. A malicious extension, or other code already executing in that process, is still on the inside. App-bound encryption changes who may call. It does not mean “once the field is AES-256-GCM, the fill logic in memory cannot see the password.”
Two sentences keep getting swapped, and they answer different questions. “My Chrome is newer than 127, so every saved password has moved” treats a version number as a migration receipt. In July 2024 Google listed passwords as a later expansion. A build number of 130, 140, or higher only shows that the browser is past the cookie starting point. “Someone can still read passwords with the old user unwrap, so app-bound encryption does nothing” is the other overreach. That observation shows that some profiles, or some rows, are still on the older door, or that the sample is describing the older door. It does not show that the new door has been publicly written off as failed.
| What you can see | What that supports | What it leaves open |
|---|---|---|
| The password field is AES-256-GCM | The on-disk field is not the plaintext password | Whether every local program is unable to read it |
| Windows wraps the key with DPAPI | Other users and cold-boot attacks are outside the stated protection | Whether a program started as the logged-in user is outside it |
| Chrome 127 app-bound encryption, cookies first | On data that has moved, an outside program’s older unwrap fails | Whether password rows on this machine have moved, and whether in-process code can still read them |
| The password manager lists a site | That site was saved at some point | Which generation of key wrapping that row uses |
| Offer to save passwords is turned off | Later logins can stay out of the store | Whether rows already in the store have been removed |
What the 25 September report can prove
On 25 September 2026, Deepa B at K7 Labs published an analysis of a Windows program built from a Python malware-as-a-service builder. Security write-ups repeated it over the following days. The payload looks for user-data folders of 17 Chromium-based browsers and reads saved passwords, payment-card records, browsing history, and session cookies. It also reads Firefox history and cookies, so the Chromium AES-256-GCM sentence does not describe every browser on the machine. For Chromium logins, K7 says newer password fields are stored with AES-256-GCM, and the key is recovered through Windows user-level data protection, with a fallback to the older protection method. K7 states that the lab did not establish how widely the builder had been distributed or how many machines were infected.
That description lines up with the older door from the previous section. The right to unwrap sits with the current user, so a program in the same logon can stand inside the door, and AES-256-GCM only keeps the field from being plaintext. The report is not written as “this sample passed Chrome’s app-identity check,” and it does not supply a victim count you can turn into “your Chrome is already affected.” Reading the cipher name in the headline as “encryption has failed,” or as “so my password store is certainly safe,” both take a step the report does not take.
The same class of report also mixes two materials that are easy to treat as one. A stolen session lets someone use a login you have already completed, for as long as that session stays valid. Changing the password on the original site retires the next password login. It does not, by itself, retire sessions that were already issued. Those come down when you sign out other sessions in the account’s device list, or when the site revokes them. That job is separate from how strong the password-store cipher is. An earlier check of “a password change does not remove a session that is already enrolled” is in the passkey note linked below. They are not one switch.
Do not unwrap your own password store to “see if the news is true,” and do not practice with a real banking, email, or cloud-console password. The check below only looks at whether the settings page lists saved sites and whether the save prompt is still on. Revealing plaintext and exporting the whole store are outside this check.
Check the saved list, not the database
A slogan and a headline cannot describe the browser in front of you. A throwaway account on a test site is enough. The four steps below stay inside the current browser. You do not copy the profile folder out to do them.
- Open the browser’s own password manager (Settings, under passwords or autofill, or the browser’s password page from the address bar). Read the site list only: does email, banking, a cloud console, or a code host each have a row? Do not reveal plaintext, and do not export.
- Find “Offer to save passwords,” or the switch with the same job. It decides whether the next login can be stored. Turning it off does not delete rows that are already there. Removal is per row in the list, or through the browser’s control for clearing saved passwords.
- Open About and confirm the browser is still receiving official updates. Write down the version. The version does not prove that password fields have moved to app-bound encryption. The settings page will not print the words DPAPI or app-bound. Do not go looking through key labels in the profile folder to settle it.
- If you already suspect this computer is running a program you did not install: do not click “show password” on this machine. On a device you still trust, sign out other sessions at the important sites and replace those passwords. Do not reuse one password across sites. This step limits the damage. It is not an invitation to unwrap the store on the suspect machine “to see whether a read is possible.”
A version number does not name the key generation
Chrome 127 is the version where app-bound encryption started to cover cookies. It is not the version where every saved password changed wrapping on that day. Seeing 130, 140, or a later major version only shows that the browser is past that starting point. Whether password fields have finished moving was left, in the July 2024 note, to later releases, and the interface does not display a wrapping generation. If a review sheet records the version, the next cell should say “this does not establish that the password store is app-bound,” rather than a checkmark.
The save prompt is the switch that creates a row
Many passwords enter the store because the browser asked after a successful login and a person clicked Save, not because an encryption page uploaded them. From then on, that row sits behind the door described above. If you generate a password that exists only on this device and you decline the prompt, it does not become a row in the password manager. Declining the prompt does not prove that page script never sent the password. That question belongs in the Network panel. It only proves you did not hand the string to the browser’s saved-password list.
Four ways “encrypted” gets read too far
The first over-read treats AES-256-GCM as “malware cannot read this.” The algorithm shows the field is not plaintext, and it shows that ciphertext cannot be altered without the key and still verify. If that key is wrapped with DPAPI for the current user, Google has already written that a program running as that user is not outside the protection. The cipher name and the position of the door are two lines, and they have to stay two lines in a review.
The second over-read treats “I have a Windows login password” as “the password store is immune to malware.” The login password is what keeps other accounts, and a cold-boot attack, from unwrapping DPAPI. A program that is already running after you have logged on is using that unlocked user environment. You should still set a login password. It answers a different door.
The third over-read treats “version above 127” as “saved passwords and cookies are both app-bound, and code inside the process cannot see them either.” Google’s starting point was cookies. Passwords were the expansion. App-bound encryption blocks the older unwrap from outside the browser. An extension, or other code already running in the browser process, does not go blind because that door exists.
The fourth over-read treats “every site has a different password” as “it is fine if the whole store is read.” Unique passwords stop one site’s breach from being replayed at your email and your cloud console. They do not stop a program that reads every saved row in one pass. Both controls are worth doing. They cover different failures.
FAQ
If the password manager says encrypted, can other programs on this computer still read the password?
Encrypted means the password field on disk is not plaintext. On the Windows DPAPI generation, Google wrote that the protection covers other users and cold-boot attacks, and that it does not cover a program running as the logged-in user. App-bound encryption from Chrome 127 starts with cookies: an outside program’s older unwrap fails on data that has moved, while the inside of the browser process can still read. The word “encrypted” on the screen does not tell you which generation this machine’s password fields are on.
Does Chrome 127 app-bound encryption mean malware cannot decrypt saved passwords?
No. The 30 July 2024 note lists passwords and payment data as items intended for later releases. App-bound encryption narrows the right to unwrap from “the current user” to “a browser the system component accepts.” That is why an outside program that only uses the older user unwrap fails on data that has already moved. It does not place in-process code outside the door, and it does not show that every saved password in your browser has completed the move.
Does the 25 September report mean any program can already read my Chrome passwords?
That swap is too large. The report describes a Windows program that reads saved passwords, payment cards, history, and sessions from 17 Chromium-based browsers, plus Firefox history and cookies, and it says password fields use AES-256-GCM with the key unwrapped through user-level data protection. K7 did not publish a victim count, and it did not present the sample as having passed the app-identity check. Which generation your browser is on depends on the saved list and on whether updates are still arriving, not on the cipher name in a headline.
After I change a site password, do the saved sessions stop working too?
Not always. A password change retires the next login that uses that string. Sessions already issued often remain until you sign out other sessions in the account’s device list, or until the site revokes them. The same class of program takes sessions and saved passwords together. Changing one password and leaving other sessions signed in handles the password, not the session.
Does FastPwd write a generated password into the browser’s saved-password list?
It does not write that list, and the site has no password vault of its own. A row appears only if you accept the browser’s save prompt. Random mode uses crypto.getRandomValues, allows 6–128 characters, and defaults to 16. The result is not uploaded. Ready to use, with no account. If a program on this machine can already read the current tab or the clipboard, it can see plaintext on the page. The upload boundary does not replace that limit.
See “not saved” on a generator you can open now
If you want the difference between “a password appeared” and “a password entered the browser’s store” to be visible, open FastPwd’s password generator. No signup. In random mode, keep the default of 16 characters and generate a throwaway string. If the browser offers to save it, decline. Go back to the password manager: the test site should not have gained a new row. FastPwd does not keep a password vault, and it does not write the browser’s saved-password list for you.
Generation uses crypto.getRandomValues. Length runs from 6 to 128 characters, with 16 as the default. Shorter than 8 is flagged as weaker. The result is not uploaded. Open DevTools, choose Network, enable preserve log, and search request lines and bodies for the full string. It should not appear in a business request. That search shows this run did not leave the tab as an HTTP body. It does not show that a local program is unable to read the page or the clipboard. If this computer is already untrusted, generate and sign in on another device.
If you also want to see whether a string looks like a public high-frequency weak password, take a different throwaway string into Password Audit. The password you test is not uploaded. A miss does not prove the string has never appeared on the web. A hit only means it is too common. Do not paste the real password you are about to start using, and do not export the browser password store so you can test the export.
If that string has to reach one other person a single time, keep it out of a ticket body that will land in server logs. Use Burn-Link instead: the server stores ciphertext only, the key sits after # in the link, and both creating and reading need no account. That channel answers “how do I hand this over once.” It does not make an old password already saved in the browser safe. Delete that older row in the password manager, and replace it from a device you trust.
Further reading
To check a “local, not uploaded” claim, search Network for a canary, in How to check if browser encryption never uploaded plaintext. A password change does not retire a session that has already been issued: see They called to update your passkey. Why that lure steals the session, not the Passkey. A local weak-password list can catch common weak passwords and is not a full-web breach lookup: see What a local leaked-password list can prove, and why it is not a full-web lookup.