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.
This logic is perfectly aligned with the Chromium threat model. Once an attacker gains administrator access, it is game over by definition.
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.
It's a very standard defense-in-depth technique to put secrets between guard pages and only make the secret page readable when needed. That way any inadvertent access, be it programming error or exploit, simply causes a segfault, unless it's raced with a valid access (in a multithreaded or shm context) or the exploit explicitly changed the permission bits. Most memory disclosure vulnerabilities don't allow you to do that.
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.
Or unless you need to reenter password/offer fingerprint after certain amount of time. Which, I think, should be the actual standard, and typically is with the apps like Bitwarden.
>> Microsoft has no interest in making their browser less secure than its upstream.
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.
Look, Ihate Microsoft too but Edge is just Chrome with a different skin, so they'd have to have gone out of their way (and spent money paying engineers) to make Edge less secure than Chrome/ium.
The whole point of them using chromium shows how little they care.
The old edge wasn't used much no but that wasn't due to its engine. Most people don't even know what a browser engine is.
They just didn't want to bother making a browser. But they want to benefit from the marketing advantages of having a browser so now they just lift along with chrome.
I think they do care, but they care about relevance, not browser monoculture. Doesn't matter how good Trident was, no one was ever going to use it. Even Firefox is barely hanging on, and the only reason Safari is still somewhat relevant is because it's the only choice on iOS.
And my relevance I mean their bread and butter, enterprise, not consumers. Edge is what lets MS give enterprise IT departments maximum control without the grumbling of "we'd rather have Chrome" from the end users.
Well that's the thing. I don't think anybody didn't use Edge because it was a different engine. The majority of users have no idea that edge is just chrome now.
It's just when they moved to chromium they also stepped up the marketing around it and all the lock-in in Windows and that's really what got people to use it. Basically the same thing they did to make IE a monopoly.
They also really heavily pushed companies to start using it. Every time we had a call with a MS consultant and we shared a screen they had to bitch about us not using edge, as if they were on commission or something. Eventually they manipulated our leadership into mandating edge to all employees. It's totally locked down now too, it's terrible for the users.
But my point is, they could have done this with the trident version of edge too. I've never heard anyone complain about compatibility. Whenever people didn't want to use edge it was because of a (totally justified) distrust of Microsoft. We should never give control over the internet to them again after what they did with IE (making it a monopoly through illegal means and then leaving it to wither away full of security holes). But unfortunately at work they have got them to remove all other browsers :(
In recent years we've also had browser-exploitable vulnerabilities that allowed reading arbitrary memory as a regular user, but slowly or without full control over the locations. I think wiping credentials as soon as possible after use is a very sensible precaution, even if it's only a moat.
I wonder about those kinds of exploits that sit on a webpage, but what stops someone from injecting their payload on a sites login page? JS can grab the password in plaintext in such a scenario, at which point the password manager does not save you. Can we normalize Passkey more?
I think the point is that you can have arbitrary website read the browser’s memory so example.com can read the password for example.org and example.net.
It's surprisingly hard to do the compiler or cpu may see a write without a read and optimize it away. Windows has a SecureZeroMemory and a few other barrier primitives but not all languages reach to it
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.
I think we've moved away from the secure perimeter thinking and towards defense in depth - if that list of passwords helps you get somewhere other than the vault, removing the post-it improves security. Vaults get infiltrated all the time - and often in partial ways like being able to see into the vault but not reach in.
Defence in depth matters, but an analysis here shows that the same mechanism used to breach the outer layers (getting administrative access) can be used to breach the next layer (more thoroughly prodding Edge or Chrome to give up passwords).
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/TEEs, Realms, Secure Elements, Security chips, etc.
True. But then your hardware dies, and you're locked out of every account you own. It is objectively good security, but has a ton of usability headaches yet to be really solved.
I've seen orgs move to passkeys only, then offer reset-questions (e.g. city of first job, etc); because the Customer Service volume/workflow wasn't figured out.
I swear, people who idolize passkey security must never travel anywhere.
PS: "just have more devices with passkeys", they invariably say.
Yeah right because people are made of money, everyone has the forethought, and a 2nd laptop in the US is a great asset when you're in Poland and can't login anywhere.
I've been avoiding passkeys but more and more websites are trying to push them, and one website I use now requires them. I've already got a password manager! I don't need to change everything again!
The good thing about this is they thereby also support FIDO2 hard tokens such as Yubikey. The UI is often confusing but you can always tell it to provision the key to your Yubikey rather than the OS enclave.
That doesn't help if my machine (with only a few USB ports) gets stolen/lost with the token in it. It doesn't help if some of my devices only have USB-C and some only have USB-A. It's absolutely more annoying than letting my password manager fill things in or typing in a 6 digit code from my authenticator app.
Passkeys are password replacements that can't be breached/leaked/etc... I don't think they are necessarily supposed to replace 2-factor, however it's probably more secure than some of the weaker forms of 2-factor auth.
Given that in order to access your password manager's vault often requires 2-factor (or should at least) it's a level of security that I am comfortable with.
I take it a step further and host the password manager vault within my home network. My home network does not expose anything publicly except a WireGuard port, it's completely locked down. I have to VPN in to access the vault.
The subject here is literally websites trying to push passkeys on users. That is who is asking us to.
About every week now Amazon tries to trick me into creating a passkey. It doesn't even ask, it just goes ahead and triggers my browser passkey creation mechanism without my consent. PayPal recently tried to force me to create one too and I had to kill and restart the app because that was the only way to skip it. I'll stick to my password with 2FA, thanks.
It's wildly obnoxious that browsers don't let you generally suppress these prompts.
And if you take the nuclear option and strip your browser of WebAuthn support, then you obviously can't use any passkeys, which doesn't work for me - I have two sites where I do want to use passkeys (because it's the only way to avoid SMS-based MFA on every login), but I never want to see passkey prompts for any other sites.
We have now gone from having to “redo everything” to being asked to switch to a passkey by a grand total of one website.
I’ll be honest I’ve heard a lot of griping about passkeys but I have gone out of my way to switch over to them and have had precisely zero issues over the dozens of sites that I’ve bothered to make the switch on. Login flow is simpler and doesn’t rely on a browser extension guessing at login fields or trying to figure out when passwords change.
Me giving an example of one major website (actually, I gave two) is all that is needed to disprove your claim. I could provide plenty more examples of major websites asking me to, but I don't need to. I could provide plenty of examples of people telling people to "redo everything" with passkeys, but your own comment is literally advocating the same thing...
Please don't mischaracterize the conversation that is plainly visible for all to see. Just accept that you tried to suggest that nobody is asking users to switch to passkeys, and you were wrong. It seems like your error is that you just haven't been seeing it personally, since you switched on your own before the nagging started, and so you weren't aware of it. Well, now you are.
They literally are. You can easily google articles telling people to use passkeys for all their supported accounts. I'm not going to google it for you.
Why you are trying to claim the opposite is beyond me.
>We have now gone from having to “redo everything” to being asked to switch to a passkey by a grand total of one website.
Yeah right.
When passkeys were rolled out, I was told it's OK because "passwords are always going to be required to be an available alternative".
Now we've moved the goalposts to "it's just one website".
>Sometimes the new thing really is just better.
And sometimes your backpack is stolen when you're traveling, with your phone and laptop (happened to me in Poland), and you need to log into your accounts while having none of your devices or your phone number available.
What if I told you I was not one of the people saying that? You can’t take two different people with two different opinions and say “Look! You’ve moved the goalposts!”
If passkeys are significantly better, passwords will gradually stop existing. If passwords are, passkeys probably won’t catch on.
> And sometimes your backpack is stolen when you're traveling, with your phone and laptop (happened to me in Poland), and you need to log into your accounts while having none of your devices or your phone number available.
I personally keep a separate YubiKey that—along with a memorized password—is sufficient for me to retrieve my password manager database and unlock it. If this is a sufficiently motivating use-case for you, you too can take these kinds of steps to mitigate the risk.
But since we’re playing the “what if” game, what happens if you get early onset dementia and forget your passwords? Pray tell then what?
>I personally keep a separate YubiKey that—along with a memorized password—is sufficient for me to retrieve my password manager database and unlock it.
So, basically, having to create and maintain a backup device to keep separately from my laptop/phone in case they get stolen, make sure I don't lose it, but carry it with me everywhere like a crucifix.
That, and still having to remember and use a password, because otherwise the thieves get control of everything once they steal my device.
Sure. That's not objectively better than passwords which don't require this sort of hassle.
At the very least because it still requires a password.
>you too can take these kinds of steps to mitigate the risk.
OK. I can. I don't want to have to do these kind of steps, or any other dance to mitigate the real risks that passwords already protect me from.
Passkeys mitigate risks which I don't run into (”what if someone learns my password?”), while introducing others.
They are a convenience for people who run the system because they off-load those risks onto users.
>But since we’re playing the “what if” game
You're playing games with contrived hypotheticals.
I've had my laptop, phone, and wallet stolen on an overseas trip.
>what happens if you [...] forget your passwords?
I click the "forgot your password?" link which every website that uses passwords has.
Having a notebook in a vault with passwords also solves this problem.
I don't get a sudden onset of dementia which causes amnesia when I travel.
But I've lost my devices and had them stolen from me overseas.
It was a big enough hassle even though I did have the passwords.
If a website only supports one passkey on one device, it's a shitty implementation. To be fair many websites have shitty implementations, so I ended up using my yubikeys to store the secret for OTP codes.
Having only one device that has authority to log into your accounts is obviously not a good security model.
Of course they are. Lots of websites are pushing it, including while using dark patterns. You need to sometimes explicitly cancel an onboarding flow to avoid Passkeys.
For people who only use passwords having an extra device can help too. Google does not necessarily permit a login with a backup code, so to me it seems ideal to grab a spare phone, log into important accounts, and store it with a trusted party/friend.
It could be very difficult to login to an account like Gmail from overseas in the event of PC+phone[+hardware key] theft. Maybe no big deal if you can port your number to a new phone right away. Or maybe the trusted friend can help (unless Google still finds the login suspicious after all, no idea there)
I travel a lot. By train, plane, and car. I also use passkeys when possible. I have multiple Yubikeys, stored in different locations. I also have a password manager, where I typically keep track of which logins aren’t yet backed up across physical tokens.
It takes a bit of effort, but it’s not impossible.
Yes, it means that in the event of catastrophic failure I might not be able to log in to some services until I get to one of the backups. I haven’t been able to imagine a scenario where that would be truly problematic.
>Yes, it means that in the event of catastrophic failure I might not be able to log in to some services until I get to one of the backups. I haven’t been able to imagine a scenario where that would be truly problematic.
No need to imagine!
Remove all passkeys from your phone and laptop, then go somewhere overseas without any of those Yubikeys.
Have fun enjoy a "not truly problematic" scenario of getting your Yibikeys from "multiple locations" you don't have access to, while being cut off from your messengers, email, bank account, etc.
Bonus points for having your card locked or stolen at the same time.
Or, imagine the backpack with your passkeys devices being stolen on an overseas trip.
I don't have any passkeys on my phone or laptop. They're all on the Yubikeys.
I don't really see a difference with (some) password managers, though. If you use one of the keepasses, and you lose access to the file, you're in the same situation right?
And yeah, you're right, there is a risk of inconvenience. I'm not debating that. I just choose to organise my life in such a way that it is just an inconvenience.
It's literally at https://github.com/Joker-vD/keepassdb/raw/refs/heads/master/... in my case, plus a couple of other free hosting sites that support easy updates/reuploads, so losing access to it requires losing access to Internet — in which case you don't really need any (alright, most) of your passwords because you need Internet to connect to the services that require those passwords.
OK, fair, I never left my keepass file exposed like that when I used keepass.
If I remember correctly, 1Password still requires a "vault key" in addition to your username and password, and it was definitely too long and not used often enough for me to remember.
oh lawd, yes it does come down to 'who has the power to reset your account', and very few people want to take the path of 'no one has the power' in the case of lost credentials.
A lot of services have password reset email features. If the email account has passkey you're screwed. But restore by snail mail can be possible but slow (for paid services). More secure? Don't know but same category of problems already known due to sim swapping attacks in mobile sector. But for sure the Mail account is a high value target.
Storing passkeys in a database may be possible but complex to do it right e.g. backup verification, avoiding to leak while backup etc.
Banking has no selfservice password reset. A lot of work for customer support due to identification. Nobody wants to do that for free and if the accounts are freenyou may get DOSed by bots which trigger passwort resets.
Yes, but the pin uses the TPM which allows other things like only ever allowing a low number of guesses before requiring a reset of the pin (using a password or other mechanism)
>It is objectively good security, but has a ton of usability headaches yet to be really solved.
Thank you, then this is still true today?
Disappointing the rollout was botched (recall cross platform and password manager difficulties). Haven’t done research since but even with some new UIs and flows promoting passkeys in the past couple months, haven’t regained my trust either.
> 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.
The way to think about security is as a system of layers, each of which filters out ever more sophisticated attackers.
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.
The Swiss cheese model is what people use to sell you more 'security' related software systems that inherently involve more problems. (Also cheese is not very durable, even the kind without holes.)
That is redundancy in my book. I don’t expect holes in my GNSS devices. And if you want to be sure, bring three, because two GNSS units with different readings are not very helpful.
I don't expect holes. But both devices are exposed--something could happen to one of them. And since I like going out in the middle of nowhere I assume I either have to get myself out, or if that's impossible summon help. I don't want a single point of failure on either of these.
isn't it at risk of any code pathway that somehow allows you exceed a buffer and read memory unbounded? Then a nefarious web page could capture that? That's a huge exposure surface.
Agreed. I keep seeing "high priority" "vulns" that require so much system access to actually exploit that they become pointless. If an untrusted process can read your memory or run as an administrator you have already lost.
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.
Many of them also have vested interests in furthering corporate authoritarianism, which is why letting users have full control over their devices is considered a security risk to them.
All true, but it is still bad style. There is no need to keep decrypted passwords in memory the user hasn’t even used in the session (or after they logged in to a certain website).
What I don’t need doesn’t need to live unencrypted in my RAM. Of course I do. It is standard behaviour of iOS, and of a lot of password managers. If someone grabs my laptop and runs, at least they can’t capture my hn account.
So as a user, when I go to paste any password, I first need to log in with biometrics, yet any random user process can just snag the password from memory?
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.
What's the threat model where not storing them all at once provides any benefit?
If someone has admin it's already game over. Can just hook the browser to retrieve all passwords on demand.
An attacker might only have read access. Could be a read buffer overflow like Heartbleed, a partial sandbox escape, a sophisticated Spectre-type vulnerability, a cold boot attack, or something mundane like a core file taken from a crashed process that gets into the wrong hands.
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.
This comment feels like it's written by AI. Anyway, PAGE_GUARD helps you get around VirtualProtectEx, which is a very common way of detecting userspace cheats.
I'm not the other commenter (and I believe you that it's not AI), but I'd guess it's mostly the first line: a short affirmation followed by "The problem is ...." feels like the sort of formula the LLMs love to use. (Not trying to imply that there's anything inherently wrong with it, of course.)
While we're at it, I'm under the impression that the recent LLMs have also co-opted "genuinely", which I'll never forgive them for—first they stole my em-dashes, and now they're stealing my adverbs too?!
I do see how your comment is similar to AI writing (a couple other comments explain) but it did NOT set off my AI trigger. I think it's just clear writing.
Without context, sentences like this mean nothing. So it's borderline a non sequitur. A threat model can be literally anything. Me giving my PC to someone at Best Buy, letting my grandma write assembly, or throwing my PC out the window can be a "large threat model." Nonsense sentence.
> 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.
To the uninitiated this seems right, but really there's so much glossing over, it feels written by a non-expert that just read the first chapter of a "hacking for dummies" book. I've written anti-cheats and have even done some some hardware stuff, so I say this with some degree of experience: writing a userspace hack/cheat is pretty hard without a zero-day. Most stuff won't easily get PROCESS_VM_OPERATION permissions, also those are (afaik) logged by the kernel, so you can easily see if some weird "DefinitelyNotACheat.exe" executable or "NotABadLibrary.dll" requested them, so it's a pretty janky way of getting access to memory you shouldn't.
> That's the problem with same-user process isolation, it is a hugely leaky abstraction. There is no magical "just set this bit" fix.
Again, this is a non sequitur. No one said (or at least I didn't) that there's a "magical" bit. You're not even arguing against a strawman, it's almost like we're having two different conversations.
> 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.
Also seems right, and it kinda' is, but code signing is notoriously easy to circumvent, "anti-injection hardening" can mean like three million different things, etc. I dunno, just sounds like someone that's never done this stuff before. Like, not bringing up Detours[1] when talking about "anti-injection" just seems like weirdly avoiding the ONE canonical way of doing this, which just about every single hacking/cracking book covers. Idk, weird omission.
Also, no one in their right mind would attach a debugger, as that's trivial to detect[2]. I guess it could be a decent proof of concept, but no serious hacker would ever go that route. (Also, if I remember correctly, you also need to ship some special DLLs that have the actual debugging helpers—and same with Detours, so might as well do that).
Just wanted to give my justification for the accusation. Maybe I'm wrong and maybe that's why I'm getting the downvotes, so my bad.
I think you are viewing this with your anti cheat experience where detection is key. Can a regular process protect against another regular process reading its memory through PROCESS_VM_READ or can it at best only detect that it happened?
They also act as access alarms[1]. Why even comment if you didn't bother to read the docs?
> The PAGE_GUARD protection modifier establishes guard pages. Guard pages act as one-shot access alarms. For more information, see Creating Guard Pages.
Absolutely wrong. Are we writing the same code here? Page guards are for all userspace access. (In fact, I think kernel space might also trigger them, but can be circumvented. PS: I'm being polite :) Kernel space 100% triggers them, but can be cleverly circumvented by fucking with logs.)
Thankfully our recent experiences with OpenClaw have given us all a lot of faith that users are extremely diligent in what processes they allow access to what information.
If passwords are fetched remotely on-demand, you steal the account API key from memory.
If they're encrypted, you steal the master password or decryption key.
... So what's your solution?
I think it’s more about layers of defense being always better than relying on a single point of failure.
IIRC those bugs could only steal data, not do remote execution. If you did not store even the encrypted passwords in memory, getting the password/key to them compromised would still keep you safe, or at least upgrade it to a timing attack.
They want obscurity and think it's security. Everything needed to get the passwords must be present in memory but they don't want to be able to actually see the passwords directly.
This is a fallacious belief. While there is not point in obscurity, there is much value in not making it trivially easy to read passwords, as most exploits (especially of chromium) are not full user compromise, but the ability to massage some memory structures and read/write specific interesting bytes.
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.
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.
> 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...