> 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...
I doubt this is an Edge-specific issue. Microsoft has no interest in making their browser less secure than its upstream.
> Why aren‘t physically-local attacks in Chrome’s threat model?
> We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your device as you, or who can run software with the privileges of your operating system user account. Such an attacker can modify executables and DLLs, change environment variables like PATH, change configuration files, read any data your user account owns, email it to themselves, and so on. Such an attacker has total control over your device, and nothing Chrome can do would provide a serious guarantee of defense. This problem is not special to Chrome — all applications must trust the physically-local user.
https://chromium.googlesource.com/chromium/src/+/148.0.7778....
That being said any single password, when used, passes through so many layers and components that it's likely impossible to even just wipe the contaminated memory locations. But that's fine, the password database is opened for most of the browser's lifetime, any given password actively being used is a rare event in comparison.
It absolutely ain't Edge-specific. Firefox (AFAICT) also keeps stored passwords in clear-text unless encrypted with a passphrase (which is not the default on desktop; on Android there's a fingerprint/PIN check to access them, but I don't know offhand if there's any encryption involved with that).
Really this is true of most credentials stored within applications; unless you're providing a decryption key on open (whether explicitly or on OS-level login using some keychain mechanism), the stored credentials are probably plaintext.
Microsoft has every interest in spending as little money as possible on edge, just enough to keep people swalling the tripe. User privacy is not a thing at MS and hasnt been for decades. Plaintext passwords in a MS product is just another monday. It will take decades more to convince me they have changed.
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.
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.
It honestly feels like more and more "security" people and businesses have less interest in actually securing systems and more in marketing themselves and their business hence the tendency to make every niche attack into a five alarm fire.
What am I missing here?
[1] https://learn.microsoft.com/en-us/windows/win32/memory/memor...
This is the load bearing argument and it is false.
There are plenty of circumstances were you can grab a piece of process memory but not all of it.
There are plenty more circumstances where you can grab process memory but not kernel memory.
There are plenty more (almost all) where you can dump kernel and process memory but you can't access the keys stored in the TPM module.
Leaving the door open for anyone with the smallest exploit is stupid and bad security.
Additionally, the passwords could be kept encrypted in another process, and decrypted on demand, essentially a password vault. This lets you use techniques like biometric or physical button approval for password use, and reduces the likelihood of a browser memory dump containing passwords.
File audit capabilities in the OS can also be tuned so that only the vault application should be reading the vault file. Make info stealers job difficult.
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.
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.
> 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-...
* 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...
https://yourpasskeyisweak.com does not mention Edge.
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.
At least with Keepass it's locked in an encrypted store and only available exactly when I need it to be. I can take other precautions if I want when I want to access it.
With your browser's password manager you're stuck with the slop you were given.
https://security.googleblog.com/2024/07/improving-security-o...
> In Chrome 127 we are introducing a new protection on Windows that improves on the DPAPI by providing Application-Bound (App-Bound) Encryption primitives. Rather than allowing any app running as the logged in user to access this data, Chrome can now encrypt data tied to app identity, similar to how the Keychain operates on macOS.
That's gonna be a big ol' [CITATION NEEDED] from me, dawg.
I keep looking for frameworks that do it the right way, holding critical data encrypted all time, but it isn't a thing most people worry about.
E.g. if my app needs a db connection I can ask a vault service but I need creds for that. The vault service can rotate the creds very fast but is it addition security.
The password should only exist in the process memory for the few lines of code to open that database connection, and then wiped after you got the handle.
Ideally, homomorphic encryption should be used instead.
Malicious code can read some/all memory in your container, but not necessarily execute. Plenty of such vulns exist.
> Where do you store the decryption key?
Not in memory. Either nowhere after use, on the filesystem, or otherwise accessible on-demand by performing IO.
Stopping the spread is just as important as protecting any individual machine.
I think it's worthwhile considering this. There's a reason why password managers ask for a master password or passkey after 10 minutes. Since I thought Chrome relied on an encrypted enclave, it isn't quite feasible to extract passwords easily even with root access.
Yes, you shouldn't leave your computer unattended. But that doesn't mean designing products that make exploiting the inevitable slipup fatal.
It seems to depend on whether you're on a desktop or mobile device. [1]
> macOS 13 Ventura was released in 2022 and for portable Macs with Apple CPUs Apple introduced a feature known as ‘Accessory Security’ (also known as ‘Restricted Mode’)
> By default, portable Macs (i.e. laptops) with an Apple CPU running macOS 13 Ventura or newer version of macOS will require the end user to authenticate and approve a Thunderbolt device when initially connected.
> Stationary Macs (i.e. desktops) with an Apple CPU running macOS 13 Ventura or newer version of macOS do NOT implement the ‘Accessory Security’ feature. As a result, Thunderbolt devices will be automatically approved and authenticated when initially connected.
Anecdotally, I have had Dell and Lenovo laptops with Thunderbolt and in Linux I had to manually approve each new device before it would function. [2]
[1] https://kb.plugable.com/docking-stations-and-video/do-i-need...
[2] https://wiki.archlinux.org/title/Thunderbolt#User_device_aut...
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).
https://security.googleblog.com/2024/07/improving-security-o...
> In Chrome 127 we are introducing a new protection on Windows that improves on the DPAPI by providing Application-Bound (App-Bound) Encryption primitives. Rather than allowing any app running as the logged in user to access this data, Chrome can now encrypt data tied to app identity, similar to how the Keychain operates on macOS.
That's on top of a host of reasons why biometric authentication isn't very good security, so if you care at all about your data, just use a password. If you're any good at typing, it's usually just as fast and convenient, anyway.
It's slower on a phone, but a randomly-generated four-digit PIN's one-in-ten-thousand security is still better than a fingerprint, and most phones do allow more digits.
This was in the middle of the 2003 security stand-down and he started by asking "How are your QA skills? Cause in a couple months Bill (Gates) is going to forget all about security and we'll get back to writing code the way we always have. And we won't need a Security Architect so we'll have to find a job for you and I was thinking QA."
Corners of Microsoft doing stupid things with respect to security isn't an accident. It's a natural consequence of their culture.
That being said... There are (or at least were) some amazingly good security brains in Redmond. It's just that not all groups got the security memo.
This is the future and I think IBM got such technology like 50 years ago envisioned.
But.. saved passwords are not the same thing as "secrets" the browser uses. It has to be able to provide plain text passwords to websites. This is a really bad feature browsers should just not have to begin with, but they do, and I don't see a better way to use this.
In the past, they used to store the passwords in sqlite dbs, but now they've moved away from that at least.
From an attack perspective, there maybe some instances where you can dump memory, but you can't attach a debugger to the process without getting caught. so it does make a little bit of a difference there, but microsoft will probably tell you this isn't a security boundary that's being crossed. They can store it via DPAPI in lsass, and if lsass isolation is enabled (only on physical computers, default on win11) even SYSTEM privilege won't get you the credentials.
But what's the idea here, you have access to the browser, but you can't visit the site the password is saved for to make it "in use" and in plain text, so you can dump the password? I mean, even if you don't have access to the desktop, you can just start msedge.exe with the URL for the site as an argument and trigger the password retrieval.
Edge has done a lot to improve credential security, even DPAPI's existence itself is huge. If your research has meat, that's great but I don't see it here.
This feels like some "researcher" hyping themselves up to me, but I could be wrong.
Also, I really despise how they posted this on twitter, not even considering the political landmine there, I can't see the comments or threads on there without logging in. I can't visit the site on mobile without being redirected to download the app. I just wanted to mention that if you use X as a security professional in this day and age, my opinion of you drops by like 50% immediately. I don't care if you use bluesky, vk, telegram, discord,facebook, threads or whatever else, twitter is the worst place for you to share your work and you should know better.
I would think this is a local vulnerability assuming Windows works as other OSs.
