HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
52% Positive
Analyzed from 2476 words in the discussion.
Trending Topics
#memory#passwords#password#user#process#access#security#https#microsoft#edge
Discussion (92 Comments)Read Original on HackerNews
> 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...
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.
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.
It also makes other attacks much harder. Namely I don't need to worry about some zero-day in my password manager.
We should care about all kinds of attackers, and not assume that the protections against the most sophisticated will obviate the protections against the least sophisticated.
[0] https://en.wikipedia.org/wiki/Cloudbleed
[1] https://learn.microsoft.com/en-us/windows/win32/memory/memor...
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.
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.
https://support.microsoft.com/en-us/topic/export-passwords-i...
With said cookie you can absolutely impersonate a user for while (potentially needing to evade user agent string checks and the like but often not)... but it will expire and then your access should be ended. If the site is well designed actions like password changing should also re-require the user's password instead of allowing anyone with just the cookie from proceeding with the action.
If it is done right cookies are pretty decently secure at keeping your secrets safe but, for convenience they do lower the security that could be accomplished with more involved techniques.
As an aside Oauth's key -> token approach is basically identical to password -> cookie (assuming best practices are in place).
I would think this is a local vulnerability assuming Windows works as other OSs.
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).
> Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials.
> Credential Guard uses Virtualization-based security (VBS) to isolate secrets so that only privileged system software can access them.
https://learn.microsoft.com/en-us/windows/security/identity-...
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.
EDIT: Yes, he claimed that for online password managers, not keepass. I thought the argument was about password managers in general.
> Good examples of simple and safe password managers are keepass and keepassx
Nb. The above refers to KeePassX. No idea what the KeePass without the x is about. Naming things. So hard.
No fancy browser plugins, the ability to autotype, the db file could be synced with anything you can sync files.
Working search - not sure about BW, but it's opensource implementation (Vaultwarden nowadays?) simply didn't allow to search for the fields you didn't scroll yet to.
The biggest problem is lack of multi-edit functionality - you need keep it in mind if you leave somehwere a copy running 24/7.
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.
* I don't want to speak past my own experience so checking my work, Windows can store passkeys in a TPM if available but falls back to storing on disk... https://helgeklein.com/blog/checking-windows-hello-for-busin...
> Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials.
> Credential Guard uses Virtualization-based security (VBS) to isolate secrets so that only privileged system software can access them.
https://learn.microsoft.com/en-us/windows/security/identity-...
That's gonna be a big ol' [CITATION NEEDED] from me, dawg.