Hacker News Reader

Comment by enkrs | Hacker News Reader

Browser password managers with passkeys are more convenient for me, but a pass vault can still be useful for recovery codes and API keys.

I used pass for a while but couldn’t see what threat model it actually solves:

If you let GPG agent cache your key, any script (e.g. an npm post-install) can just run `pass ls` or `pass my/secrets` and dump all your credentials. At that point it’s basically just full-disk encryption with extra steps—might as well keep everything in ~/passwords.txt.

If you don’t cache the key, you’re forced to type your long GPG password every single time you need a secret.

I tried a YubiKey for on-demand unlocking, but the integration is clunky and plugging it in constantly is a pain if you need passwords multiple times per hour.

I eventually switched to Bitwarden.

View on HN

That’s true for any password manager. If the database/store is unlocked (so the master password is cached or available in RAM), all passwords can be extracted. You have to lock the password manager when you don’t need it.

In fact, with Bitwarden, the cached password is exposed to the browser that has a large attack surface (including interacting with random remote servers). There was just a vulnerability in most browser based password managers including Bitwarden that would allow a remote attacker trick a user send out their passwords.

I use Bitwarden but mostly for non-critical passwords.

Doesn't good 2factor minimize a large attack surface like this?

I like the idea of storing password data in individual encrypted files and using git to store changes, but I wonder if it creates more friction to retrive the information. I havent tried this solution yet. I will when I get more time. It seems like this solution would benefit from a more standardized specification for storing and retrieving information. I known its not every persons cup of tea, but maybe some kind of separated add-on for streamlining this process could be beneficial.

>That’s true for any password manager

Modern operating systems isolate individual apps such that a malicous app can not access the RAM of another app. There is a difference between not making an effort to protect passwords and requiring an OS exploit to do so.

Memory isolation doesn't really help, though. If you have a malicious process running under the same user account as your password manager, it's still game over since that process could e.g.

- capture keyboard input - capture your screen - silently install browser extensions to capture your credentials - modify your shell config, .desktop files, $PATH, … to have you e.g. call a backdoored version of your password manager, or put a modified version of sudo on your $PATH that logs your password (=> root access => full memory access) - …

You can use Qubes OS for true VM-level isolation, or use hardware security keys where possible, or run sensitive applications in dedicated VMs.

I think that in general it is game over the moment you have malicious processes running. I use firejail for most applications, which I believe is the bare minimum, or bubblewrap.

Yeah. Personally, I'm crossing my fingers for SpectrumOS[0] to make things a bit easier. As the developer notes on her website[1]:

  <qyliss> I have embarked on the ultimate yak shave
  <qyliss> it started with "I wish I could securely store passwords on my computer"
  <qyliss> And now I am at the "I have funding to build my own operating system" level

[0]: https://spectrum-os.org/

[1]: https://alyssa.is/about/

What else can you tell me about Spectrum OS? Is it actively maintained? Is it usable? How does it compare to Qubes OS?

Also what do you think about Subgraph OS[1]? Although I think it is not maintained anymore, or is it?

[1] https://subgraph.com/img/sgos.png (old image which I remembered it by) (https://web.archive.org/web/20241206072718/https://subgraph....)

I don't know how usable SpectrumOS is so far – I guess we'd have to compile it ourselves in order to find out. Either way, it is being developed quite actively, see https://spectrum-os.org/git/

As for how it compares to Qubes, I don't think I'll be able to tell you more than https://spectrum-os.org/design.html & friends. I suppose the upshot is:

- KVM instead of Xen

- One VM per application

- Single file system for user data (to which users can grant VMs access on a folder-by-folder basis)

- Package system from NixOS (nixpkgs) for reproducibility & immutability

Ugghh, once again I forgot that HN removes line breaks unless you use double line breaks or indent by 2 spaces, and now it's too late to edit my comment.

@dang People keep running into this. (See e.g. this comment[0] from a few days ago.) It also makes it rather awkward to write lists IMO. What's the reason for removing line breaks and could this be changed?

[0]: https://news.ycombinator.com/item?id=44946386

For modern operating systems capturing keyboard input is locked down to avoid keyloggers. Capturing your screen requires explicit user permission to do so, popping up a dialog. Apps are isolated so another app can't interfere and install a browser extention or modify shell configs, etc.

And modern operating systems are being … ? macOS, I assume?

Can you name one of these modern operating systems?

iOS is a modern operating system.

It's also impossible to use it for anything productive.

The OS protections apply to all applications. In addition, the job of agents like gpg-agent or ssh-agent is to protect secret keys while they are cached (like preventing OS writing keys to swaps). You can configure them to erase keys after a certain time, require user’s confirmation for each key operation, store gpg keys in internal TPM or external hsm, and would talk to the agent through specific sockets.

Unlike browser-based password managers, the agents don’t continuously interact with the browser code and remote elements (probably don’t have network access at all).

One area that matters that I forgot to mention in my comment below is that, as a result of all above, Pass doesn’t check the domains and doesn’t protect against phishing. There might be extensions, but at that point, you might as well use keepassxc.

I store my passwords on an encrypted file partition sqlite database. My script grabs the pass and immediately closes the partition afterwards.

You can also just encrypt your passwords into individual encrypted files (one for each password) and have your script clear the gpg agent after a passfile is decrypted.

If you can spare a USB port you can use one of their Nano keys that just stays plugged in.

Even if someone/malware was to steal my yubikey pin they'd still need to convince me to tap the thing over 1,000 times to steal all my passwords.

I just leave my yubi plugged in. It requires a physical touch anyway (at least you can configure it for that which I have). And my place is physically secure.

The good thing also is that unlike with fido2 you only have to enter the pin once for OpenPGP. Then it stays unlocked while it's plugged in. But still needs the physical touch for every password. Perfect and convenient for me.

It also works great on mobile with openkeychain and password store. Both are not really maintained now but I don't really care because the encryption is in hardware anyway (yubikey over nfc)

> a pass vault can still be useful for recovery codes and API keys

You might already be aware of this, but Bitwarden also has a CLI client that can be used for this purpose, at least casually.

And can run a local webserver to expose an API (though they still need to tighten up security on it)

I can't remember how but pass for me works in brave browser and Firefox, as well as on mobile. It's my only password manager. I'm assuming some browser plugin.

You can configure the yubikey to need a PIN and/or touch to authorise the use a GPG key.

My main issue with pass is that it doesn’t work great on iOS with yubikeys.

Is the biometrics step (fingerprint reader) on macOS much different from a ubikey? I imagine implementation may have some differences, but in practice it seems I can already protect access to my GPG key using the built-in reader, so what’s the advantage of ubikey in that respect? Genuinely curious.

The TouchID is bound to a device - of course, I could copy my secret into a secure enclave that is only accessible through TouchID. Could even just store my GPG key there. With a Yubikey, I generate the key on an airgapped device and store it on the Yubikey. No other piece of hardware ever needs to see my secret key in plaintext. I could achieve the same with TouchID, generate the secret key inside the enclave, but then I cannot move the secret keys out without some other computer baring witness to that.

I really do not want to give Apple any more leverage over me, I'm looking to minimize it.

it took a while to get it to work well, but I use yubikey here, and recommend it. I do need to find and pulg it in sometimes, but overall might leave it plugged in. and I have it configured to require a touch for every operation

Is bitwarden in some way able to protect passwords while still being unlocked?

Reply on news.ycombinator.com