This feels like a case of "It rather involved being on the other side of this airtight hatchway"[1]. If you can read arbitrary process memory, you're probably also in a position to just dump out the passwords by pretending to be the user in question.
> If an attacker gains administrative access on a terminal server, they can access the memory of all logged‑on user processes.
If an attacker has administrative access, they can also attach a debugger to every chrome process and force it to decrypt all the passwords. The only difference this really makes is in coldboot attacks, but even then it's still not clear whether it makes the attacker's job slightly easier, or allows an attack that's otherwise not possible.
Security isn't black and white. If i leave a post-it note of my logins on my monitor, that's definitely less safe than in a unlocked drawer, and so on.
If I leave a post-it note of passwords on my monitor inside a vault to which only I have access, it’s not a big deal. That’s the point of the “airtight hatch” metaphor.
Right; but in the scenario of this Tweek, you've invited someone untrustworthy into the vault and are then freaking out because they can see the post-it note of passwords. It is inherently irrational.
This issue is inherently unfixable by ANY password manager, because the process model of the underlying OS isn't itself secure. No obfuscation will work, because the password manager itself needs to de-obfuscation it before use (and that memory too is dump-able).
All adding in-memory obfuscation does it make ignorant people feel better, while not moving the security needle even an inch.
I think we’re largely in agreement. I do think there’s some benefit in reducing the amount of time that a password is in cleartext in memory. But it’s pretty far down the list.
> This issue is inherently unfixable by ANY password manager, because the process model of the underlying OS isn't itself secure
Usually the confidential bits are hardware isolated away from the supervisor (host kernel/OS) in Enclaves, Realms, TEEs, or Secure Elements, Security chips, etc.
> If i leave a post-it note of my logins on my monitor, that's definitely less safe than in a unlocked drawer, and so on.
Having passwords on post-it notes does make certain types of attacks much easier. For instance, coworkers hacking other coworkers, or people burglarizing the office. None of which really apply to the "If an attacker gains administrative access on a terminal server" scenario.
Continuing the analogy, what Edge is doing is like leaving cash in unlocked cabinets inside a vault, and what Chrome's doing is locking those cabinets with a padlock. Sure, having the padlocks makes the cash more secure, but if someone went through all the effort into breaking the vault (terminal server), a padlock probably isn't going to stop them. This is especially true nowadays with AI coding agents and ready-made stealers available for sale online.
Reading arbitrary process memory can be done as a standard user. No admin needed. Any Win32 program can do it. You just can't access the memory from processes that are admin-level.
This is not true. The canonical way to prevent access is via PAGE_NOACCESS[1]. Obviously, running as admin or in kernel mode breaks the whole thing since you can re-call `VirtualProtect` on that page and open it up.
This is accurate as far as page protection goes. The problem is the largest threat model.
If Process A and Process B are running in the same user context on a desktop OS, PAGE_NOACCESS is not a strong boundary by itself. Process B may be able to obtain PROCESS_VM_OPERATION/PROCESS_VM_READ, change the page protection with VirtualProtectEx, inject code that calls VirtualProtect inside Process A, load a DLL, attach as a debugger, duplicate useful handles, or tamper with the executable. That's the problem with same-user process isolation, it is a hugely leaky abstraction. There is no magical "just set this bit" fix.
On a desktop OS, once an evil process runs under the same user context, you are relying on process DACLs, integrity levels, code-signing, anti-injection hardening, and file-system protections. You can plug one path and still have several others.
There's little hope of protecting against a snooper seeing the passwords you actually use, since they have to exist in plaintext at some point. But there's no reason to expose the entire password database when no passwords are even being used.
This is 100% that case. Basically every form (like this very one I'm typing in) is held in userspace memory un-encrypted. And yet lawyers and doctors and CIA operatives all use forms to type very sensitive stuff in.
It would be stupid, wasteful, and overly-complex to encrypt forms just in case some malicious process somehow got ring0 access. In that case, a keylogger is likely more useful anyway. And you're fucked even if you are encrypting stuff (as keys are likely also somewhere in memory[1] and they need to be—gasp—unencrypted). There's no free lunch.
Stupid Twitter thread meant to rage-bait for engagement.
[1] They could also be on disk or on some peripheral, but still fully readable by a motivated-enough hacker.
Password managers often go through quite some hassle to keep passwords 'safe' in memory. However, I often do not get the attack model of many of those tools. Tools like keepass e.g. go through quite to register a browser plugin. But then anyone with normal user rights can extract that key from the browser and do everything with it. Also this whole 'trust this browser' stuff of web apps seems strange if one e.g. can read the cookie store easily...
The headline here says "stores in memory", which sounds pretty much identical to me. Can you elaborate on what you consider the difference between "loading" and "storing" into memory?
When someone says passwords are ‘stored’, the assumption will always be ‘stored on disk’. ‘stores in memory’ is not an accurate representation because memory is inherently volatile and they are loaded there temporarily. Plaintext on disk is egregious, plaintext in memory is considerably less so.
Linux stores plenty of passwords in clear text in /etc and $HOME and this is considered acceptable by most users. These same people also believe the TPM is a spy chip.
Really in /etc plain text? I could see some random app possibly doing that somewhere in ~/.config, but I don't think Linux itself stores passwords in plain text for systemwide use.
In this day and time Microsoft should really know better. But I have seen this, and worse, happen over and over again in some fortune 500 companies with ERP and in-house systems.
I would think this is a local vulnerability assuming Windows works as other OSs.
For anyone that thinks this is an Edge-specific dunk, Chrome does not hash your passwords and they are cleartext in memory while Chrome is running (which for most users is always).
This is generally true of every application that handles sensitive data. Unless you explicitly clear that memory, it's likely to hang around forever.
For example, here is a 2019 writeup from KeePassXC with similar notes: https://keepassxc.org/blog/2019-02-21-memory-security/ - even though they explicitly clear sensitive data, there is still a window of opportunity.
During my time working on confidential computing, we had a variety of demos showing similar attacks against lots of different datastores, scripts, etc. That's just how computers work and your options are very limited if this is part of your threat model (imo just confidential computing and, if you can handle the performance hit, fully-homomorphic encryption).
Password hashes are one-directional lossy storage. If a password manager "hashed your password" it would be essentially deleting your password and replacing it with something else which cannot be used to log into anything. The password MUST be recoverable to plain-text to replay it to a website.
But you're correct that Chrome, Firefox, Edge, Lastpass, BitWarden, even Keepass have the same issue. It is an Operating System limitation, not a password manager problem.
Browser-based password management serves the purpose of locking users into a specific browser; I'd much rather have the freedom to switch browsers at will without the cognitive tax of securely moving all my creds every time I want to switch my main browser.
That's not what that is saying. It's saying don't use an _online_ password manager instead of the browser one. In the very opening they state that simple implementations are great and even lists some. Then the rest of the article dives specifically into online password managers, which are something else.
Out of curiosity, why KeePass versus Bitwarden? I've been using Bitwarden for years, but if there's a specific reason I should be using KeePass instead, I'm open to changing.
KeePass is just an encrypted database file with UI around it for usability. You can keep the db on a USB drive, sync it through a cloud storage, e-mail it to yourself, whatever ... It's really not that complicated. BitWarden is the above as a service, I reckon.
Nb. The above refers to KeePassX. No idea what the KeePass without the x is about.
Naming things. So hard.
Bitwarden has taken investor money, sadly. It's still in good shape for the moment. But the time will come when they place profits above other needs; it's a matter of when, not if.
If it is a process, running in the same user context, with the ability to read/dump arbitrary memory -- As the KeePass database is decrypted it would "store all passwords in memory in plain text" too.
The fix isn't Edge Vs. Chrome. Vs KeePass Vs. Bitwarden, it is "How do I have my passwords exist in a different execution context than [evil process able to read all memory]?"
Android and iOS have an "answer" to this problem. Desktop OSs having all processes running side by side in the user's execution context, do not. It is only as secure as the least secure process running.
This makes me miss running Qubes a few years ago, and keeping BitWarden in a separate VM from everything else. I've never felt as secure as when I had that setup.
I'm pretty sure macOS is more like iOS in this respect. At the very least, the passwords are typically secured biometrically and only the one being used is actually decrypted at the time of use.
This feels like a case of "It rather involved being on the other side of this airtight hatchway"[1]. If you can read arbitrary process memory, you're probably also in a position to just dump out the passwords by pretending to be the user in question.
> If an attacker gains administrative access on a terminal server, they can access the memory of all logged‑on user processes.
If an attacker has administrative access, they can also attach a debugger to every chrome process and force it to decrypt all the passwords. The only difference this really makes is in coldboot attacks, but even then it's still not clear whether it makes the attacker's job slightly easier, or allows an attack that's otherwise not possible.
[1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
Security isn't black and white. If i leave a post-it note of my logins on my monitor, that's definitely less safe than in a unlocked drawer, and so on.
If I leave a post-it note of passwords on my monitor inside a vault to which only I have access, it’s not a big deal. That’s the point of the “airtight hatch” metaphor.
Right; but in the scenario of this Tweek, you've invited someone untrustworthy into the vault and are then freaking out because they can see the post-it note of passwords. It is inherently irrational.
This issue is inherently unfixable by ANY password manager, because the process model of the underlying OS isn't itself secure. No obfuscation will work, because the password manager itself needs to de-obfuscation it before use (and that memory too is dump-able).
All adding in-memory obfuscation does it make ignorant people feel better, while not moving the security needle even an inch.
I think we’re largely in agreement. I do think there’s some benefit in reducing the amount of time that a password is in cleartext in memory. But it’s pretty far down the list.
> This issue is inherently unfixable by ANY password manager, because the process model of the underlying OS isn't itself secure
Usually the confidential bits are hardware isolated away from the supervisor (host kernel/OS) in Enclaves, Realms, TEEs, or Secure Elements, Security chips, etc.
One more reason to use hardware-bound passkeys and not passwords.
> If i leave a post-it note of my logins on my monitor, that's definitely less safe than in a unlocked drawer, and so on.
Having passwords on post-it notes does make certain types of attacks much easier. For instance, coworkers hacking other coworkers, or people burglarizing the office. None of which really apply to the "If an attacker gains administrative access on a terminal server" scenario.
Continuing the analogy, what Edge is doing is like leaving cash in unlocked cabinets inside a vault, and what Chrome's doing is locking those cabinets with a padlock. Sure, having the padlocks makes the cash more secure, but if someone went through all the effort into breaking the vault (terminal server), a padlock probably isn't going to stop them. This is especially true nowadays with AI coding agents and ready-made stealers available for sale online.
> Having passwords on post-it notes does make certain types of attacks much easier.
It also makes other attacks much harder. Namely I don't need to worry about some zero-day in my password manager.
Reading arbitrary process memory can be done as a standard user. No admin needed. Any Win32 program can do it. You just can't access the memory from processes that are admin-level.
This is not true. The canonical way to prevent access is via PAGE_NOACCESS[1]. Obviously, running as admin or in kernel mode breaks the whole thing since you can re-call `VirtualProtect` on that page and open it up.
[1] https://learn.microsoft.com/en-us/windows/win32/memory/memor...
This is accurate as far as page protection goes. The problem is the largest threat model.
If Process A and Process B are running in the same user context on a desktop OS, PAGE_NOACCESS is not a strong boundary by itself. Process B may be able to obtain PROCESS_VM_OPERATION/PROCESS_VM_READ, change the page protection with VirtualProtectEx, inject code that calls VirtualProtect inside Process A, load a DLL, attach as a debugger, duplicate useful handles, or tamper with the executable. That's the problem with same-user process isolation, it is a hugely leaky abstraction. There is no magical "just set this bit" fix.
On a desktop OS, once an evil process runs under the same user context, you are relying on process DACLs, integrity levels, code-signing, anti-injection hardening, and file-system protections. You can plug one path and still have several others.
And if the malware is running as admin, you’re pretty fucked either way
There's little hope of protecting against a snooper seeing the passwords you actually use, since they have to exist in plaintext at some point. But there's no reason to expose the entire password database when no passwords are even being used.
This is 100% that case. Basically every form (like this very one I'm typing in) is held in userspace memory un-encrypted. And yet lawyers and doctors and CIA operatives all use forms to type very sensitive stuff in.
It would be stupid, wasteful, and overly-complex to encrypt forms just in case some malicious process somehow got ring0 access. In that case, a keylogger is likely more useful anyway. And you're fucked even if you are encrypting stuff (as keys are likely also somewhere in memory[1] and they need to be—gasp—unencrypted). There's no free lunch.
Stupid Twitter thread meant to rage-bait for engagement.
[1] They could also be on disk or on some peripheral, but still fully readable by a motivated-enough hacker.
Yeah, you can probably do the same thing to pam on linux... just attach gdb to openssh or your getty login process.
Does this tool access an Edge instance running on the same machine? Couldn't you then just simply export all saved passwords anyway?
https://support.microsoft.com/en-us/topic/export-passwords-i...
Password managers often go through quite some hassle to keep passwords 'safe' in memory. However, I often do not get the attack model of many of those tools. Tools like keepass e.g. go through quite to register a browser plugin. But then anyone with normal user rights can extract that key from the browser and do everything with it. Also this whole 'trust this browser' stuff of web apps seems strange if one e.g. can read the cookie store easily...
Anyone have a link to the source code for this .exe? Would love to see _how_ it's extracting them.
https://xcancel.com/L1v1ng0ffTh3L4N/status/20513083298807197...
To be fair, 'loads into memory' and 'stores' are not the same thing.
The headline here says "stores in memory", which sounds pretty much identical to me. Can you elaborate on what you consider the difference between "loading" and "storing" into memory?
When someone says passwords are ‘stored’, the assumption will always be ‘stored on disk’. ‘stores in memory’ is not an accurate representation because memory is inherently volatile and they are loaded there temporarily. Plaintext on disk is egregious, plaintext in memory is considerably less so.
A reminder that Edge is just Chromium plus some Microsoft hooks for automated SSO.
Its Microsoft doing Microsoft things
Linux stores plenty of passwords in clear text in /etc and $HOME and this is considered acceptable by most users. These same people also believe the TPM is a spy chip.
Really in /etc plain text? I could see some random app possibly doing that somewhere in ~/.config, but I don't think Linux itself stores passwords in plain text for systemwide use.
You really need to upgrade to UNIX Version 6 or later. Some of the improvements since 1974 are well worth having.
> Linux stores plenty of passwords in plain text in /etc
That's gonna be a big ol' [CITATION NEEDED] from me, dawg.
Wifi passwords in /etc/netplan files, is one I can think of.
I thought Linux stored plain text credentials owned by root that require elevated permissions.
In this day and time Microsoft should really know better. But I have seen this, and worse, happen over and over again in some fortune 500 companies with ERP and in-house systems.
I would think this is a local vulnerability assuming Windows works as other OSs.
For anyone that thinks this is an Edge-specific dunk, Chrome does not hash your passwords and they are cleartext in memory while Chrome is running (which for most users is always).
This is generally true of every application that handles sensitive data. Unless you explicitly clear that memory, it's likely to hang around forever.
For example, here is a 2019 writeup from KeePassXC with similar notes: https://keepassxc.org/blog/2019-02-21-memory-security/ - even though they explicitly clear sensitive data, there is still a window of opportunity.
During my time working on confidential computing, we had a variety of demos showing similar attacks against lots of different datastores, scripts, etc. That's just how computers work and your options are very limited if this is part of your threat model (imo just confidential computing and, if you can handle the performance hit, fully-homomorphic encryption).
Password hashes are one-directional lossy storage. If a password manager "hashed your password" it would be essentially deleting your password and replacing it with something else which cannot be used to log into anything. The password MUST be recoverable to plain-text to replay it to a website.
But you're correct that Chrome, Firefox, Edge, Lastpass, BitWarden, even Keepass have the same issue. It is an Operating System limitation, not a password manager problem.
Please use a dedicated password manager, instead of a browser-based one. KeePass is likely the best going forward.
@taviso had claimed the exact opposite: https://lock.cmpxchg8b.com/passmgrs.html
EDIT: Yes, he claimed that for online password managers, not keepass. I thought the argument was about password managers in general.
Where?
> Good examples of simple and safe password managers are keepass and keepassx
Browser-based password management serves the purpose of locking users into a specific browser; I'd much rather have the freedom to switch browsers at will without the cognitive tax of securely moving all my creds every time I want to switch my main browser.
I agree. It's especially problematic when you use different browsers on different devices and operating systems.
That's not what that is saying. It's saying don't use an _online_ password manager instead of the browser one. In the very opening they state that simple implementations are great and even lists some. Then the rest of the article dives specifically into online password managers, which are something else.
You're right. Edited my comment.
Out of curiosity, why KeePass versus Bitwarden? I've been using Bitwarden for years, but if there's a specific reason I should be using KeePass instead, I'm open to changing.
KeePass is just an encrypted database file with UI around it for usability. You can keep the db on a USB drive, sync it through a cloud storage, e-mail it to yourself, whatever ... It's really not that complicated. BitWarden is the above as a service, I reckon.
Nb. The above refers to KeePassX. No idea what the KeePass without the x is about. Naming things. So hard.
Bitwarden has taken investor money, sadly. It's still in good shape for the moment. But the time will come when they place profits above other needs; it's a matter of when, not if.
If it is a process, running in the same user context, with the ability to read/dump arbitrary memory -- As the KeePass database is decrypted it would "store all passwords in memory in plain text" too.
The fix isn't Edge Vs. Chrome. Vs KeePass Vs. Bitwarden, it is "How do I have my passwords exist in a different execution context than [evil process able to read all memory]?"
Android and iOS have an "answer" to this problem. Desktop OSs having all processes running side by side in the user's execution context, do not. It is only as secure as the least secure process running.
This makes me miss running Qubes a few years ago, and keeping BitWarden in a separate VM from everything else. I've never felt as secure as when I had that setup.
I'm pretty sure macOS is more like iOS in this respect. At the very least, the passwords are typically secured biometrically and only the one being used is actually decrypted at the time of use.
Why wouldn't it? What else would you expect from the p̶e̶o̶p̶l̶e̶ masochists who subjected us to internet explorer
My brain stores all my passwords in memory in clear text too