Rendered at 02:41:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
gruez 1 days ago [-]
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 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.
cromka 1 days ago [-]
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.
formerly_proven 1 days ago [-]
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.
BobbyTables2 1 days ago [-]
Wouldn’t a guard page be readable in Linux with /proc/self/mem ? (at least read only pages are writable with it)
widelyusygas 1 days ago [-]
> It's a very standard defense-in-depth technique
Is there any software we’d be aware of which uses this technique
slurmz 1 days ago [-]
Windows and OpenSSL both do this
sandworm101 23 hours ago [-]
>> 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.
stackghost 22 hours ago [-]
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.
wolvoleo 16 hours ago [-]
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.
thewebguyd 12 hours ago [-]
> shows how little they care.
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.
NewsaHackO 1 days ago [-]
Come on, they could still get a blood sample to really verify that its the user
Lorkki 1 days ago [-]
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.
giancarlostoro 1 days ago [-]
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?
IgorPartola 1 days ago [-]
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.
traderj0e 1 days ago [-]
Or the computer's memory via Meltdown and Spectre-like attacks
anthk 17 hours ago [-]
That's why I disable JS by default with UBlock Origin. And OFC never allow JS to acces your clipbaord.
avereveard 1 days ago [-]
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
turtlebits 1 days ago [-]
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.
stouset 1 days ago [-]
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.
solidasparagus 1 days ago [-]
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.
dwattttt 1 days ago [-]
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).
Someone1234 1 days ago [-]
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.
stouset 1 days ago [-]
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.
ignoramous 1 days ago [-]
> 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.
oasisaimlessly 1 days ago [-]
No, that is actually very rare, not typical. Do you have any examples of password managers that do that?
jazzyjackson 1 days ago [-]
One more reason to use hardware-bound passkeys and not passwords.
Someone1234 1 days ago [-]
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.
kenniskrag 21 hours ago [-]
> But then your hardware dies
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.
kenniskrag 21 hours ago [-]
Edit:
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.
jazzyjackson 1 days ago [-]
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.
alterom 1 days ago [-]
>your hardware dies
Or your backpack gets stolen.
Oops.
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.
StilesCrisis 1 days ago [-]
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!
stouset 1 days ago [-]
Your password manager almost certainly already has baked-in passkey support.
StilesCrisis 1 days ago [-]
It does, but what's your point? Why should I redo everything?
stouset 1 days ago [-]
Nobody is asking you to?
crazygringo 1 days ago [-]
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.
Marsymars 1 days ago [-]
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.
stouset 22 hours ago [-]
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.
Sometimes the new thing really is just better.
crazygringo 12 hours ago [-]
You claimed "Nobody is asking you to".
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.
stouset 9 hours ago [-]
> > Why should I redo everything?
> Nobody is asking you to?
Nobody is in fact asking you to change everything.
crazygringo 7 hours ago [-]
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.
alterom 21 hours ago [-]
>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.
Pray tell then what.
stouset 9 hours ago [-]
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?
alterom 7 hours ago [-]
>along with a memorized password—
So, your solution is passwords with extra steps.
Thanks but no thanks.
>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.
bartvk 21 hours ago [-]
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.
dboreham 24 hours ago [-]
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.
Arainach 24 hours ago [-]
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.
nightski 17 hours ago [-]
Get a better password manager? Most store passkeys.
Arainach 13 hours ago [-]
If the passkey can be stored in the password manager, then there's no second factor and what's the point?
nightski 12 hours ago [-]
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.
12 hours ago [-]
Barbing 1 days ago [-]
>"just have more devices with passkeys"
Confirms that strategy then
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)
alterom 21 hours ago [-]
>It could be very difficult to login to an account like Gmail from overseas in the event of PC+phone[+hardware key] theft
Literally happened to me in Poland, which is why I avoid passkeys like the plague.
(The thief got caught months later. That didn't help me.)
>Maybe no big deal if you can port your number to a new phone right away.
T-Mobile won't mail a SIM card overseas, and I doubt others will either. There is no "maybe", it's a certainty that you won't be able to.
>Or maybe the trusted friend can help
Yeah, my wife literally mailed me SIM card to Poland.
It took over week.
And a "trusted friend" would first have had to get it somehow.
>Or maybe the trusted friend can help (unless Google still finds the login suspicious after all, no idea there)
At least I logged into my accounts from that city before the laptop and phone were stolen, so my logins were not "suspicious".
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.
Joker_vD 1 days ago [-]
> It takes a bit of effort
That's a wild understatement. For most users, having a password manager is already very near to the upper bound of acceptable friction.
alterom 20 hours ago [-]
>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.
Again: pray tell, then what?
slau 13 hours ago [-]
> Remove all passkeys from your phone and laptop
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.
themaninthedark 1 days ago [-]
At my work we required a complex password <15 characters lower + cap, number and symbols.
Updated to Windows Hello and passkey.
Now I can use a 4 digit pin to login.
mjmas 24 hours ago [-]
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)
Barbing 1 days ago [-]
>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.
gruez 1 days ago [-]
> 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.
forgotaccount3 1 days ago [-]
> 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.
RajT88 1 days ago [-]
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.)
LorenPechtel 1 days ago [-]
Swiss cheese applies to more than just security systems.
Hiking with two GPS-capable devices is Swiss cheese.
slow_typist 22 hours ago [-]
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.
RajT88 1 days ago [-]
[dead]
ButlerianJihad 1 days ago [-]
That was an enlightening read, considering the colloquial meaning of "your firewall security is like Swiss cheese"
What's next? A system so secure that you can drive a truck through it? A honeypot in the center of a wasp nest?
yjftsjthsd-h 1 days ago [-]
Okay. Can you describe an attack / threat model where it would matter in this particular case?
keithnz 1 days ago [-]
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.
Dylan16807 1 days ago [-]
I'm pretty sure a read exploit in a web page wouldn't be in the same process as the passwords.
If you can cross over to the main Edge process, you can probably get it to remove any encryption it applied itself.
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.
userbinator 1 days ago [-]
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).
netrap 11 hours ago [-]
So you decrypt each time you need it? What is the difference in the attack surface?
cush 1 days ago [-]
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?
What am I missing here?
asdfman123 1 days ago [-]
So you're saying it's an Edge case?
Dwedit 1 days ago [-]
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.
dvt 1 days ago [-]
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.
dvt 1 days ago [-]
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.
Someone1234 1 days ago [-]
> This comment feels like it's written by AI.
Why exactly? I'm genuinely asking, because I feel like I get this a lot, and it is pretty frustrating.
BalinKing 1 days ago [-]
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?!
Someone1234 1 days ago [-]
Thanks for the explanation. Yeah, I use "genuinely" and "honestly" far too much; and often in odd places. It is a bad habit.
As to that comment's tone, my entire comment history is visible going back years. I'd invite people to peruse it.
verall 1 days ago [-]
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.
itemize123 23 hours ago [-]
basically very verbose and detailed but also very indirect. didn't get to the point till the end.
dvt 1 days ago [-]
> The problem is the largest threat model.
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?
Dwedit 1 days ago [-]
Guard pages are one-shot exceptions used for growing the stack.
dvt 1 days ago [-]
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.
Guard pages are for the process that creates them, they're not for the other processes that try to read the memory.
dvt 22 hours ago [-]
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.)
Hikikomori 19 hours ago [-]
Could you not use VirtualProtectEx to strip PAGE_GUARD?
Even so, none if these methods offer protection, at best you can get some detection, but that doesn't matter when they got your passwords already.
dvt 16 hours ago [-]
[dead]
LtdJorge 1 days ago [-]
And if the malware is running as admin, you’re pretty fucked either way
munk-a 1 days ago [-]
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.
jurf 21 hours ago [-]
Yeah because Meltdown and Spectre [0] weren't a thing.
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?
tardedmeme 1 days ago [-]
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.
wat10000 1 days ago [-]
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.
hWuxH 4 hours ago [-]
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.
angry_octet 1 days ago [-]
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.
colechristensen 1 days ago [-]
>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.
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.
dvt 1 days ago [-]
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.
ylk 1 days ago [-]
For reference, this is how Google says Chrome stores passwords encrypted in memory and uses an elevated service to prevent other processes from impersonating Chrome and gaining access to the plain text passwords: https://security.googleblog.com/2024/07/improving-security-o...
nitwit005 1 days ago [-]
That appears to be storage at rest (on disk), rather than in memory.
ylk 14 hours ago [-]
You're correct, thank you. Sadly I can't edit my comment anymore. Sorry for the confusion.
crummy 19 hours ago [-]
I recall chrome used to let you reveal passwords with a simple button press in the UI. I think their conclusion at the time was if an attacker had local access there was no point in pretending they were hidden.
m-schuetz 17 hours ago [-]
I still found it insane to display passwords that easily. Sometimes I give brief access to my PC to friends, family, acquaintances, or even colleagues, and they shouldn't be able to see my passwords with a simple button. It's like leaving your bike out unlocked, because someone with the right tools can break the locks anyway.
antasvara 13 hours ago [-]
> It's like leaving your bike out unlocked, because someone with the right tools can break the locks anyway.
Not to strain the analogy, but it's more like not locking your bike when it's in your locked apartment (the apartment being your computer). The thought being that if someone puts the time and effort into breaking into your apartment, a bike lock isn't going to do anything to stop them.
jeroenhd 17 hours ago [-]
I think it makes perfect sense. I want to see my passwords without having to re-enter my system password every time.
Operating systems have had guest accounts for decades for the "handing your PC to friends/family/etc." use case. Even Android phones have temporary guest accounts (though many manufacturers disable that because it interferes with their own secondary user-based hacks).
m-schuetz 16 hours ago [-]
Guest accounts are a nice theory that do not match the lived practice of scenarios such as "Yeah sure, go to the PC to add some songs to the playlist".
golem14 1 days ago [-]
Since it's not been clearly stated: One attack vector might be that I step out to the bathroom for 5 minutes without locking computer, and evil hacker just dumps all my passwords before I come back.
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.
hypercube33 1 days ago [-]
Did they ever fix PCIe over thunderbolt security? seems like the security for it prompting to enable on plug vanished in 2019...it could read memory in some systems and that probably didn't matter if your machine was locked or not
kogepathic 22 hours ago [-]
> Did they ever fix PCIe over thunderbolt security?
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]
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...
munk-a 1 days ago [-]
Cookies, if done correctly, will store a string that the server offered after a successful authentication - that string should have nothing to do with the password (it might contain some user information for logging/cross site tracking) but nothing sensitive.
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).
ylk 1 days ago [-]
There are (illegal) marketplaces initial access brokers sell session cookies on. Some companies try to defend against that by e.g. checking whether it's even possible that you travelled from place A to place B within a certain timeframe and, based on that, might invalidate your cookie. But then again attackers, depending on their sophistication, find their ways around it by ensuring they proxy their traffic via geographically close residential proxies, use the same OS and browser versions, etc.
Cookies can be up to 4kb in size - that should be enough to encode a fingerprint of your device.
munk-a 8 hours ago [-]
The cookie should always be minimal and arbitrary. If you want to fingerprint the device and have confidence in that correctness it's something you should store on the server (or at least store a hash of on the server).
Anything that is on a client device can be manipulated without your awareness.
pjmlp 21 hours ago [-]
As do almost every microservice out there, by storing credentials in environment variables, an exploit that manages to read container's memory is enough.
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.
kenniskrag 21 hours ago [-]
What's the threat model. Where do you store the decryption key?
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.
pjmlp 20 hours ago [-]
The treat model is that your container gets owned.
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.
To be fair, 'loads into memory' and 'stores' are not the same thing.
saghm 1 days ago [-]
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?
mfro 1 days ago [-]
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.
saghm 1 days ago [-]
> When someone says passwords are ‘stored’, the assumption will always be ‘stored on disk’. ‘stores in memory’ is not an accurate representation
I mean, sure, if you literally ignore the words "in memory", but by that logic you could argue that "Microsoft Edge stores" is misleading because it sounds like it's talking about retail establishments that sell the web browser, which is equally nonsense. I don't find it plausible that you think most people would see "stores in memory" would mean "stores on disk" unless you think that they don't understand the difference between memory and disk, at which point I don't think that they would be here to misread the headline.
jazzyjackson 1 days ago [-]
especially when the point of a password manager is to stick a plaintext string into a webpage, which then transmits the plain text to a remote server. passwords are just not a very good solution to keeping secrets.
StilesCrisis 1 days ago [-]
Never enter your password into a website that doesn't use https.
SAI_Peregrinus 11 hours ago [-]
HTTPS encrypts the password in transit, but the remote server (verifier) still gets the plaintext of the password. You need a PAKE to use a password without transmitting it to the verifier.
jonathanlydall 1 days ago [-]
*over any untrustworthy network.
To fair though, there are very few situations where the network is completely trustworthy, like your home network with no one else on it or a VPN direct to an HTTP server.
StilesCrisis 1 days ago [-]
My understanding was that if you have a valid https session, you are good.
A really really untrustworthy network could MITM your SSL connections and impose itself in front of all of them (Cisco IronPort?) but I think even then your browser will complain unless you've installed a proxy that allows it or a custom root certificate.
johanyc 18 hours ago [-]
Tbf the point of the post is the "even when unused" part. A memory store is still a store.
AJRF 19 hours ago [-]
I feel like there is a problem with security research where the incentive is to find scary headlines, and things that have very little impact get trotted out as world shattering revelations. This seems like one of those times - feels like an "assume a perfectly spherical cow" moment - if you are at the point where you have access to attempt to read this, the kingdom is already lost?
timedude 1 days ago [-]
That's kinda stupid. The passwords could get swapped to disk in the swap file in plaintext when memory is low by the OS.
alterom 1 days ago [-]
You say this as if accessing that file was any easier than accessing memory.
mintplant 1 days ago [-]
If I have a disk image or access to the physical drive, it's trivial. This means they can no longer be considered encrypted at rest.
munk-a 1 days ago [-]
If you're on prem or able to manipulate the machine into an OS of your choosing, yes. But with purely remote access to a device the disk is pretty decently secured (even if Window's ACLs are nightmareishly convoluted).
dist-epoch 1 days ago [-]
If your computer storage is not fully encrypted you have bigger worries than the swap file.
dlcarrier 1 days ago [-]
It is when the computer is off.
alterom 21 hours ago [-]
And if you whack someone with a wrench until they tell you the password, it's even easier!
Seriously, if someone is getting physical access to the machine to the extent where they can remove the hard drive... I doubt that it makes a difference whether the browser's password manager keeps its passwords encrypted in-memory.
dlcarrier 9 hours ago [-]
There's a huge difference in physical and criminal liability for stealing a laptop vs kidnapping someone. If tools become widespread for criminals to recover user accounts from an unpowered laptop, there's going to be an uptick in identity theft. When many cities would't even prosecute for the theft of a laptop, almost no one that's willing to steal a laptop is willing to hold someone up, which not only puts the criminal at physical risk of the victim attacking but also could result in decades of incarceration, if caught.
danborn26 20 hours ago [-]
This seems like a significant oversight for a modern browser. Credential material should be aggressively zeroed out after use to minimize the attack surface.
aslihana 1 days ago [-]
Correct me if I am wrong but chrome is-at least was- keeping passwords as raw text in Windows too. I got friend's forgotten password from Chrome on 2021 version
cj00 1 days ago [-]
Yeah it's been years but I remember seeing arguments with Google devs saying if someone had access to your local file system, you're already SOL.
thewebguyd 1 days ago [-]
I've always hated that argument. Yes, if someone as access to your local file system, you are already SOL, but if that machine is part of an org, they aren't necessarily SOL except for now those plain text passwords can potentially be used for easier lateral movement to hit other, more privileged accounts (if you had access/had them saved in that password manager). At minimum, those credentials can now be used to phish the rest of your organization.
Stopping the spread is just as important as protecting any individual machine.
Hikikomori 1 days ago [-]
Chrome added app bound encryption of cookie files in 2024.
testemailfordg2 17 hours ago [-]
That's interesting, then that UAC prompt asking to enter login credentials to view existing saved password is useless.
zx8080 1 days ago [-]
The only important question is: does Chrome store passwords in the same way as Edge?
peterdemin 1 days ago [-]
Sorry for off topic, is the situation the same with Safari on MacOS? I have to touch-id every time I fill the password, so it seems like it’s not available in-memory.
dlcarrier 9 hours ago [-]
Anything with biometric authentication has to store the password in a recoverable way. The fingerprint sensor isn't repeatable enough to use your fingerprint data to encrypt the password, so all it can do is compare your fingerprint data to stored data, and if it's vaguely similar, give an okay to use a copy of the password it stored.
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.
matof 1 days ago [-]
Edge is built by a company not focusing on user data-protection, so no surprise here. At least Brave and Firefox are usable and actual competitors, but have a business model based on user security rather than data.
notepad0x90 1 days ago [-]
mixed feelings on this, edge is supposed to store creds via DPAPI to the most part. you should also really not use password saving feature on edge (or any browser), it exposes you to a lot more threats that you need.
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.
pezezin 1 days ago [-]
The real mistake is that we are still using simple password authentication instead of challenge-response or public key authentication.
AzzyHN 1 days ago [-]
And firefox stores them unencrypted by default
iberator 23 hours ago [-]
That's why each page of the RAM memory should be AES encrypted with a key in hardware...
This is the future and I think IBM got such technology like 50 years ago envisioned.
ivolimmen 21 hours ago [-]
We have an automated task that runs the OWASP plugin (Maven on Java stack) that automatically creates a JIRA issue if there is any issue found.
So I pickup the JIRA ticket and look at the CVE. First things first I __READ__ the actual CVE.
Score: 7, ok that is bad
Hacker can do ANYTHING by using the tmp file on THE ACTUAL MACHINE
... drag to cancel
busterarm 1 days ago [-]
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).
bobbiechen 1 days ago [-]
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).
dist-epoch 1 days ago [-]
Windows already has a secure kernel credential store, they could move the Edge password store there with a bit of effort, minimize the splash damage when you retrieve a single password to send over HTTP from the regular user space.
> 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.
This only works if credential guard has implemented a way to build a subsequent token/value from that secret. For things like basic auth the secret would need to eventually hit the userland process that needs it in some shape or form to then embed it in the HTTP payload which is plaintext.
Someone1234 1 days ago [-]
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.
Sohcahtoa82 1 days ago [-]
I think the catch is whether the passwords are unencrypted in memory constantly, or only during a short period when the password is being used?
busterarm 1 days ago [-]
I never said that they should be hashed, just that they aren't. Just subtly pointing out what the tradeoffs are if you choose to use a password manager whose storage/access is basically always available.
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.
traderj0e 1 days ago [-]
So are you typing your password every single time you want to unlock that store? If not, where's the master password stored? I know Keychain does something advanced with the enclave.
busterarm 24 hours ago [-]
My master password is ~20 characters of strong randomness and completely in my head and has worked that way a good 10 years or so now.
FuriouslyAdrift 1 days ago [-]
A reminder that Edge is just Chromium plus some Microsoft hooks for automated SSO.
axdecces 15 hours ago [-]
sa
jmclnx 1 days ago [-]
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.
rahadbhuiya 17 hours ago [-]
good
1 days ago [-]
kronks 1 days ago [-]
[dead]
animanoir 1 days ago [-]
[dead]
WolfeReader 1 days ago [-]
Please use a dedicated password manager, instead of a browser-based one. KeePass is likely the best going forward.
EDIT: Yes, he claimed that for online password managers, not keepass. I thought the argument was about password managers in general.
echelon_musk 1 days ago [-]
Where?
> Good examples of simple and safe password managers are keepass and keepassx
busterarm 1 days ago [-]
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.
sedatk 1 days ago [-]
You're right. Edited my comment.
WolfeReader 1 days ago [-]
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.
sedatk 1 days ago [-]
I agree. It's especially problematic when you use different browsers on different devices and operating systems.
75central 1 days ago [-]
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.
dcanelhas 1 days ago [-]
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.
kelvinjps10 1 days ago [-]
Bitwarden is cloud bases keepass is local
justsomehnguy 1 days ago [-]
It's a program with a file database.
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.
WolfeReader 1 days ago [-]
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.
jazzyjackson 1 days ago [-]
Luckily offering enterprise / credential sharing features is a decent freemium model. It still wins out in keeping compatibility with self hosted vaultwarden, are there other extensions that let you point to your own domain for the encrypted blob storage?
Someone1234 1 days ago [-]
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.
jazzyjackson 1 days ago [-]
Windows 11* and MacOS also do the job as long as you're using hardware bound passkeys.
I was looking for an answer to this when it comes to using Edge password manager in particular, it uses Windows Hello as far as I know and while it does make 'synced' passkeys they don't seem to be usable anywhere than the original machine. Useful when reinstalling Windows at least.
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.
johanyc 18 hours ago [-]
Why did you stop?
WolfeReader 12 hours ago [-]
It was on a work computer, and my next job was a lot less permissive about letting us run our own OS.
My personal computer is too gaming-focused to be a good candidate for Qubes.
dist-epoch 1 days ago [-]
Windows already has a secure kernel credential store, they could move the Edge password store there with a bit of effort, minimize the splash damage when you retrieve a single password to send over HTTP from the regular user space.
> 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.
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.
fsflover 1 days ago [-]
I don't understand, who are all these people who care about security and at the same time are using Microsoft Edge. Could someone enlighten me? Does it have some specific features that somebody needs?
dev1ycan 23 hours ago [-]
They have what I think is the best implementation of vertical tabs, chrome doesn't even have them, firefox is so far behind it's not even funny anymore... brave's is terrible.
LunicLynx 1 days ago [-]
You are absolutely right, having copilot does not help at all here.
thumbsup-_- 1 days ago [-]
Its Microsoft doing Microsoft things
washingupliquid 1 days ago [-]
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.
simonh 1 days ago [-]
You really need to upgrade to UNIX Version 6 or later. Some of the improvements since 1974 are well worth having.
vondur 1 days ago [-]
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.
tgv 1 days ago [-]
I think the commenter means that some Linux applications store the passwords they need for access to external resources in plain text.
abhinavk 1 days ago [-]
You know `/etc/passwd` doesn't really have passwords in it.
josefritzishere 1 days ago [-]
I thought Linux stored plain text credentials owned by root that require elevated permissions.
cwillu 1 days ago [-]
> Linux stores plenty of passwords in plain text in /etc
That's gonna be a big ol' [CITATION NEEDED] from me, dawg.
SoftTalker 1 days ago [-]
Wifi passwords in /etc/netplan files, is one I can think of.
fragmede 1 days ago [-]
I haven't solved the problem of sensitive .env files sitting around on my computer.
spacemule 1 days ago [-]
`sops exec-env`
I have an alias set for when I'm working with opentofu:
I encrypt with openbao's transit engine and backup age key kept in a password manager, so no secrets live on disk.
jdlyga 1 days ago [-]
My brain stores all my passwords in memory in clear text too
OptionOfT 1 days ago [-]
I think in general one should not assume anything in Edge is done correctly. Microsoft Edge is the place where things get tried out my Microsoft, that's why it changes so fast. It has a built-in updater that is not tied to Windows update, and as such they can iterate incredibly fast.
mghackerlady 1 days ago [-]
Why wouldn't it? What else would you expect from the p̶e̶o̶p̶l̶e̶ masochists who subjected us to internet explorer
> 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....
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.
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.
Is there any software we’d be aware of which uses this technique
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.
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.
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.
Usually the confidential bits are hardware isolated away from the supervisor (host kernel/OS) in Enclaves/TEEs, Realms, Secure Elements, Security chips, etc.
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.
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.
Or your backpack gets stolen.
Oops.
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.
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.
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.
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.
Sometimes the new thing really is just better.
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.
> Nobody is asking you to?
Nobody is in fact asking you to change everything.
Why you are trying to claim the opposite is beyond me.
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.
Pray tell then what.
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?
So, your solution is passwords with extra steps.
Thanks but no thanks.
>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.
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.
Confirms that strategy then
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)
Literally happened to me in Poland, which is why I avoid passkeys like the plague.
(The thief got caught months later. That didn't help me.)
>Maybe no big deal if you can port your number to a new phone right away.
T-Mobile won't mail a SIM card overseas, and I doubt others will either. There is no "maybe", it's a certainty that you won't be able to.
>Or maybe the trusted friend can help
Yeah, my wife literally mailed me SIM card to Poland.
It took over week.
And a "trusted friend" would first have had to get it somehow.
>Or maybe the trusted friend can help (unless Google still finds the login suspicious after all, no idea there)
At least I logged into my accounts from that city before the laptop and phone were stolen, so my logins were not "suspicious".
That's with a password.
_____
PS: screw Citibank's mandatory phone -based "2FA".
Edit: and near 0 customer support too
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.
That's a wild understatement. For most users, having a password manager is already very near to the upper bound of acceptable friction.
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.
Again: pray tell, then what?
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.
Updated to Windows Hello and passkey.
Now I can use a 4 digit pin to login.
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.
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.
Hiking with two GPS-capable devices is Swiss cheese.
https://en.wiktionary.org/wiki/Swiss_cheese#Noun
What's next? A system so secure that you can drive a truck through it? A honeypot in the center of a wasp nest?
If you can cross over to the main Edge process, you can probably get it to remove any encryption it applied itself.
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.
[0] https://en.wikipedia.org/wiki/Cloudbleed
What am I missing here?
[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.
Why exactly? I'm genuinely asking, because I feel like I get this a lot, and it is pretty frustrating.
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?!
As to that comment's tone, my entire comment history is visible going back years. I'd invite people to peruse it.
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.
[1] https://github.com/microsoft/detours
[2] https://learn.microsoft.com/en-us/windows/win32/api/debugapi...
> The PAGE_GUARD protection modifier establishes guard pages. Guard pages act as one-shot access alarms. For more information, see Creating Guard Pages.
[1] https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
Even so, none if these methods offer protection, at best you can get some detection, but that doesn't matter when they got your passwords already.
[0] https://spectreattack.com/
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 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.
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.
Not to strain the analogy, but it's more like not locking your bike when it's in your locked apartment (the apartment being your computer). The thought being that if someone puts the time and effort into breaking into your apartment, a bike lock isn't going to do anything to stop them.
Operating systems have had guest accounts for decades for the "handing your PC to friends/family/etc." use case. Even Android phones have temporary guest accounts (though many manufacturers disable that because it interferes with their own secondary user-based hacks).
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).
Google now wants to bind credentials to a device by storing the secret in the TPM: https://blog.google/security/protecting-cookies-with-device-...
Anything that is on a client device can be manipulated without your awareness.
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.
https://en.wikipedia.org/wiki/Homomorphic_encryption
I mean, sure, if you literally ignore the words "in memory", but by that logic you could argue that "Microsoft Edge stores" is misleading because it sounds like it's talking about retail establishments that sell the web browser, which is equally nonsense. I don't find it plausible that you think most people would see "stores in memory" would mean "stores on disk" unless you think that they don't understand the difference between memory and disk, at which point I don't think that they would be here to misread the headline.
To fair though, there are very few situations where the network is completely trustworthy, like your home network with no one else on it or a VPN direct to an HTTP server.
A really really untrustworthy network could MITM your SSL connections and impose itself in front of all of them (Cisco IronPort?) but I think even then your browser will complain unless you've installed a proxy that allows it or a custom root certificate.
Seriously, if someone is getting physical access to the machine to the extent where they can remove the hard drive... I doubt that it makes a difference whether the browser's password manager keeps its passwords encrypted in-memory.
Stopping the spread is just as important as protecting any individual machine.
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.
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.
This is the future and I think IBM got such technology like 50 years ago envisioned.
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.
I would think this is a local vulnerability assuming Windows works as other OSs.
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...
https://yourpasskeyisweak.com does not mention Edge.
My personal computer is too gaming-focused to be a good candidate for Qubes.
> 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.
I have an alias set for when I'm working with opentofu:
`alias tfenter='sops exec-env secrets.yaml "/bin/bash"'`
I encrypt with openbao's transit engine and backup age key kept in a password manager, so no secrets live on disk.