> I doubt this is an Edge-specific issue.

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.

Come on, they could still get a blood sample to really verify that its the user

It's a very standard defense-in-depth technique to put secrets between guard pages and only make the secret page readable when needed. That way any inadvertent access, be it programming error or exploit, simply causes a segfault, unless it's raced with a valid access (in a multithreaded or shm context) or the exploit explicitly changed the permission bits. Most memory disclosure vulnerabilities don't allow you to do that.

That being said any single password, when used, passes through so many layers and components that it's likely impossible to even just wipe the contaminated memory locations. But that's fine, the password database is opened for most of the browser's lifetime, any given password actively being used is a rare event in comparison.

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?

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

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.

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.

> 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.

Okay. Can you describe an attack / threat model where it would matter in this particular case?

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.

[1] https://learn.microsoft.com/en-us/windows/win32/memory/memor...

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).

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.

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.

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.

It is when the computer is off.

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?

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.

https://learn.microsoft.com/en-us/windows/security/identity-...

Where?

> Good examples of simple and safe password managers are keepass and keepassx

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.

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.

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.

Bitwarden is cloud bases keepass is local

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.

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.

Windows 11* and MacOS also do the job as long as you're using hardware bound passkeys.

* 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...

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.

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.

https://learn.microsoft.com/en-us/windows/security/identity-...

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.

You really need to upgrade to UNIX Version 6 or later. Some of the improvements since 1974 are well worth having.

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.

You know `/etc/passwd` doesn't really have passwords in it.

I thought Linux stored plain text credentials owned by root that require elevated permissions.

> Linux stores plenty of passwords in plain text in /etc

That's gonna be a big ol' [CITATION NEEDED] from me, dawg.