181–190 of 243 posts
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,…
Earlier quoted context omitted.
You say this as if accessing that file was any easier than accessing memory.
It is when the computer is off.
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.
Earlier quoted context omitted.
>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.
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 ge…
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?
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.
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.
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.
Earlier quoted context omitted.
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 wi…
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 geogr…
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...
Earlier quoted context omitted.
Guard pages are for the process that creates them, they're not for the other processes that try to read the memory.
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.)
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.
Earlier quoted context omitted.
> 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.
> 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_NOA…