Rendered at 21:38:44 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
gruez 3 hours 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.
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.
turtlebits 3 hours 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 3 hours 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 9 minutes 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.
Someone1234 2 hours 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 2 hours 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 2 hours 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.
jazzyjackson 2 hours ago [-]
One more reason to use hardware-bound passkeys and not passwords.
Someone1234 2 hours 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.
Barbing 11 minutes 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.
jazzyjackson 2 hours 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 hours 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.
Barbing 3 minutes 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)
slau 52 minutes ago [-]
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.
StilesCrisis 1 hours 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 13 minutes ago [-]
Your password manager almost certainly already has baked-in passkey support.
gruez 2 hours 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 2 hours 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 2 hours 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.)
ButlerianJihad 49 minutes 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 2 hours ago [-]
Okay. Can you describe an attack / threat model where it would matter in this particular case?
keithnz 2 hours 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 2 hours 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.
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).
Dwedit 2 hours 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 2 hours 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 2 hours 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 37 minutes 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 15 minutes 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 10 minutes 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.
LtdJorge 2 hours ago [-]
And if the malware is running as admin, you’re pretty fucked either way
munk-a 1 hours 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.
tardedmeme 2 hours 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 2 hours 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.
dvt 3 hours 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 2 hours 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...
aslihana 16 minutes 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 10 minutes 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.
kleiba2 3 hours ago [-]
Does this tool access an Edge instance running on the same machine? Couldn't you then just simply export all saved passwords anyway?
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 54 minutes 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 31 minutes 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.
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 hours ago [-]
You say this as if accessing that file was any easier than accessing memory.
mintplant 1 hours 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 52 minutes 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 53 minutes ago [-]
If your computer storage is not fully encrypted you have bigger worries than the swap file.
dlcarrier 30 minutes ago [-]
It is when the computer is off.
nubinetwork 2 hours ago [-]
Yeah, you can probably do the same thing to pam on linux... just attach gdb to openssh or your getty login process.
dkenyser 3 hours ago [-]
Anyone have a link to the source code for this .exe? Would love to see _how_ it's extracting them.
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.
mfro 3 hours ago [-]
To be fair, 'loads into memory' and 'stores' are not the same thing.
saghm 3 hours 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 3 hours 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.
jazzyjackson 2 hours 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 hours ago [-]
Never enter your password into a website that doesn't use https.
jonathanlydall 43 minutes 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 31 minutes 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.
FuriouslyAdrift 2 hours ago [-]
A reminder that Edge is just Chromium plus some Microsoft hooks for automated SSO.
jmclnx 2 hours 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.
3 hours ago [-]
busterarm 3 hours 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 3 hours 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 48 minutes 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.
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 21 minutes 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?
WolfeReader 3 hours 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 3 hours ago [-]
Where?
> Good examples of simple and safe password managers are keepass and keepassx
WolfeReader 3 hours 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 2 hours ago [-]
I agree. It's especially problematic when you use different browsers on different devices and operating systems.
busterarm 3 hours 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 3 hours ago [-]
You're right. Edited my comment.
75central 3 hours 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 3 hours 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 2 hours ago [-]
Bitwarden is cloud bases keepass is local
justsomehnguy 38 minutes 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 3 hours 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 2 hours 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 3 hours 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 2 hours ago [-]
Windows 11* and MacOS also do the job as long as you're using hardware bound passkeys.
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 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.
wat10000 2 hours ago [-]
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 hours 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?
thumbsup-_- 3 hours ago [-]
Its Microsoft doing Microsoft things
washingupliquid 2 hours 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 2 hours ago [-]
You really need to upgrade to UNIX Version 6 or later. Some of the improvements since 1974 are well worth having.
abhinavk 2 hours ago [-]
You know `/etc/passwd` doesn't really have passwords in it.
vondur 2 hours 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 2 hours ago [-]
I think the commenter means that some Linux applications store the passwords they need for access to external resources in plain text.
josefritzishere 2 hours ago [-]
I thought Linux stored plain text credentials owned by root that require elevated permissions.
cwillu 2 hours ago [-]
> Linux stores plenty of passwords in plain text in /etc
That's gonna be a big ol' [CITATION NEEDED] from me, dawg.
SoftTalker 2 hours ago [-]
Wifi passwords in /etc/netplan files, is one I can think of.
fragmede 2 hours ago [-]
I haven't solved the problem of sensitive .env files sitting around on my computer.
spacemule 1 hours 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 2 hours ago [-]
My brain stores all my passwords in memory in clear text too
mghackerlady 3 hours 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
OptionOfT 1 hours 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.
> If an attacker gains administrative access on a terminal server, they can access the memory of all logged‑on user processes.
If an attacker has administrative access, they can also attach a debugger to every chrome process and force it to decrypt all the passwords. The only difference this really makes is in coldboot attacks, but even then it's still not clear whether it makes the attacker's job slightly easier, or allows an attack that's otherwise not possible.
[1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
This issue is inherently unfixable by ANY password manager, because the process model of the underlying OS isn't itself secure. No obfuscation will work, because the password manager itself needs to de-obfuscation it before use (and that memory too is dump-able).
All adding in-memory obfuscation does it make ignorant people feel better, while not moving the security needle even an inch.
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.
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.
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.
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)
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.
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.
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.
[0] https://en.wikipedia.org/wiki/Cloudbleed
[1] https://learn.microsoft.com/en-us/windows/win32/memory/memor...
If Process A and Process B are running in the same user context on a desktop OS, PAGE_NOACCESS is not a strong boundary by itself. Process B may be able to obtain PROCESS_VM_OPERATION/PROCESS_VM_READ, change the page protection with VirtualProtectEx, inject code that calls VirtualProtect inside Process A, load a DLL, attach as a debugger, duplicate useful handles, or tamper with the executable. That's the problem with same-user process isolation, it is a hugely leaky abstraction. There is no magical "just set this bit" fix.
On a desktop OS, once an evil process runs under the same user context, you are relying on process DACLs, integrity levels, code-signing, anti-injection hardening, and file-system protections. You can plug one path and still have several others.
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.
It would be stupid, wasteful, and overly-complex to encrypt forms just in case some malicious process somehow got ring0 access. In that case, a keylogger is likely more useful anyway. And you're fucked even if you are encrypting stuff (as keys are likely also somewhere in memory[1] and they need to be—gasp—unencrypted). There's no free lunch.
Stupid Twitter thread meant to rage-bait for engagement.
[1] They could also be on disk or on some peripheral, but still fully readable by a motivated-enough hacker.
https://support.microsoft.com/en-us/topic/export-passwords-i...
With said cookie you can absolutely impersonate a user for while (potentially needing to evade user agent string checks and the like but often not)... but it will expire and then your access should be ended. If the site is well designed actions like password changing should also re-require the user's password instead of allowing anyone with just the cookie from proceeding with the action.
If it is done right cookies are pretty decently secure at keeping your secrets safe but, for convenience they do lower the security that could be accomplished with more involved techniques.
As an aside Oauth's key -> token approach is basically identical to password -> cookie (assuming best practices are in place).
Google now wants to bind credentials to a device by storing the secret in the TPM: https://blog.google/security/protecting-cookies-with-device-...
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.
I would think this is a local vulnerability assuming Windows works as other OSs.
For example, here is a 2019 writeup from KeePassXC with similar notes: https://keepassxc.org/blog/2019-02-21-memory-security/ - even though they explicitly clear sensitive data, there is still a window of opportunity.
During my time working on confidential computing, we had a variety of demos showing similar attacks against lots of different datastores, scripts, etc. That's just how computers work and your options are very limited if this is part of your threat model (imo just confidential computing and, if you can handle the performance hit, fully-homomorphic encryption).
> Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials.
> Credential Guard uses Virtualization-based security (VBS) to isolate secrets so that only privileged system software can access them.
https://learn.microsoft.com/en-us/windows/security/identity-...
But you're correct that Chrome, Firefox, Edge, Lastpass, BitWarden, even Keepass have the same issue. It is an Operating System limitation, not a password manager problem.
EDIT: Yes, he claimed that for online password managers, not keepass. I thought the argument was about password managers in general.
> Good examples of simple and safe password managers are keepass and keepassx
Nb. The above refers to KeePassX. No idea what the KeePass without the x is about. Naming things. So hard.
No fancy browser plugins, the ability to autotype, the db file could be synced with anything you can sync files.
Working search - not sure about BW, but it's opensource implementation (Vaultwarden nowadays?) simply didn't allow to search for the fields you didn't scroll yet to.
The biggest problem is lack of multi-edit functionality - you need keep it in mind if you leave somehwere a copy running 24/7.
The fix isn't Edge Vs. Chrome. Vs KeePass Vs. Bitwarden, it is "How do I have my passwords exist in a different execution context than [evil process able to read all memory]?"
Android and iOS have an "answer" to this problem. Desktop OSs having all processes running side by side in the user's execution context, do not. It is only as secure as the least secure process running.
* I don't want to speak past my own experience so checking my work, Windows can store passkeys in a TPM if available but falls back to storing on disk... https://helgeklein.com/blog/checking-windows-hello-for-busin...
> Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials.
> Credential Guard uses Virtualization-based security (VBS) to isolate secrets so that only privileged system software can access them.
https://learn.microsoft.com/en-us/windows/security/identity-...
That's gonna be a big ol' [CITATION NEEDED] from me, dawg.
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.