Hacker News Reader

Comment by 14 | Hacker News Reader

Is there no way to defend against a keylogger? What can you do if a simple keylogger can steal your passwords?

"keylogger" may not be the right term here? I'm not familiar with how that term is broadly used for, but my definition of that term is a tool that logs your keypresses. Here, it seems like it was scraping your chrome/firefox data for login cookies?

Honestly there's quite a lot of malware that go against those files, I wonder if there's a way to require high privilege to accessing chrome/firefox appdata, or just block it entirely from other apps.

Yeah you're right, people miss use the term keylogger frequently. These kind of malware are broadly called "stealers" and usually do not involve keylogging.

Actual keyloggers tend to be rare nowadays due to them being easier to detect and the fact that in general the browser data is a more valuable target.

Ideally, don't use passwords: Passkeys where supported, SSH Keys, client certificates, social login via a service that does support one of these methods.

Magic link emails can also work, but are potentially vulnerable if you copy/pasted it rather than clicking depending on the keylogger's capability and clipboard visibility, although the window for attack is small, it's a much more sophisticated attack that leaves more traces (good sites will reject reuse).

Second best, also use a second factor: U2F ideally, TOTP with the same caveats as magic link emails, and at the bottom of the barrel SMS which is better than nothing but known to be very flawed.

Honestly, if you are anything other than a casual user, and don't have devices with support baked in already, it's crazy not to spend ~£60 on a pair of security keys for passkey/U2F. It's not a lot of money and is just so much more secure.

Ideally, don't use passwords: Passkeys where supported, SSH Keys, client certificates, social login via a service that does support one of these methods.

If a process has the privileges to run as a keylogger, it can also grab your local SSH private keys and possibly harvest passwords and passkeys from your local password manager vault [1]. The process has local access and since it is a key logger presumably your master password. (The complexity depends a bit on the password manager, e.g. IIRC macOS keychain always requires a roundtrip through the secure enclave).

100% this. A secure enclave or a hardware key is the only way to keep your key material safe.

Also, app sandboxing should be the default. macOS App Store Apps are sandboxed. Unfortunately, these days the standard is still for applications to have unfettered access to a user's files.

[1] Passkeys can also be on a security key, but e.g. Yubikeys only have a small number of resident key slots and I think passkeys to most people means key material synced through iCloud/1Password/your favorite cloud.

When I talk Passkeys, I definitely mean hardware by default, which is how most websites position it: it's normally described as "set up a passkey for this device" and in practice the vast majority of people using them will be using a fingerprint reader in a laptop or on their phone, because most people don't set up password managers with passkeys.

To me, using a software for passkeys is a hack only power users will do, and yes, I see it as a bad idea.

Right now I believe Yubikeys can do 25 passkeys, which is a pretty low limit, but it offers enough to protect your most important accounts, and right now I doubt many people have more than 25 sites they use that support passkeys (of course, hopefully that goes up quickly).

Aside from not using passwords or using 2FA, sandboxing helps.

A VM with GPU passthrough set up would be one example (although this is usually a pain to set up and I expect most people aren't doing it).

As a more user-friendly example, if you install an iOS app (local-model LLM and image generation apps exist), the sandboxing provided by the OS ought to be more than enough to prevent keyloggers, short of 0day exploits.

Not as secure as VMs but GPU passthrough with Docker/Podman is much easier to set up, and you can even use the GPU on the host machine at the same time.

Are you giving it access to /dev/dri, or doing some fancier sandboxing?

(Would you even need anything fancier? I think /dev/dri is supposed to isolate users.)

Nvidia provides a toolkit to do this [1], getting a GPU into a container is as easy as running `podman run --device nvidia.com/gpu=all`. The process is similar for Docker, but rootless Docker requires some extra steps IIRC.

[1] https://docs.nvidia.com/datacenter/cloud-native/container-to...

Use 2FA I'd imagine.

I mean, anything with root access can very easily use libevdev to get all keystrokes as well as mouse positions. (It's maybe 10 lines of code to do that).

So, don't run stuff as root. If it needs root access, run it in a virtual machine (personally I use qubes os for this).

Reply on news.ycombinator.com