Hacker News Reader

Comment by thecopy | Hacker News Reader

I recommend everyone to move your plantext secrets from ~/.kube/config, ~/.ssh etc into a password-manager. You can tell Claude to adjust the config files to get the secrets from 1Password when they are needed with TouchID requirements etc.

View on HN

These days I’m getting so many 1Password prompts for agents pulling env variables out of it and with very little context of what is being accessed by who (The dialog 1Password shows is pretty bad) that it would be very easy for something to slip in there.

> I’m getting so many 1Password prompts for agents pulling env variables out of it and with very little context of what is being accessed by who

This is a one-sentence horror story. I almost can't believe someone would let this happen, unless the 1Password account is not important (highly unlikely).

I know it sounds bad, but it’s the reality for most people, just like permission prompts at every corner and after each macOS / app update (“Your screenshot app is watching your screen”, no shit, that’s why I installed it).

Permission fatigue is real.

What does your sandboxing look like that you’re willing to give agents credentials real enough to store in 1Pass?

The dirty little secret of our industry is that everyone runs agents with full disk access on their machines as there's no good way to sandbox it. This also precisely why Apple posted a newsroom article a few days ago about this topic: https://developer.apple.com/news/?id=p6zjojqw

Blaming this on the user is a bit like blaming someone for doing their banking on their regular day to day computer instead of an air gapped machine.

Speak for yourself :-)

Yeah, I don’t know about that. We use VDI and dedicated agent accounts. Sort of like I’ve got my super user account for production server access via a different VDI, now I’ve got my -agent account for the agent VDI.

I have been using Yubikeys for years, according to this guide: https://github.com/drduh/yubikey-guide

The nice thing is that using the private key requires physical touch. That means that AI itself (or a remote attacker, for that matter) can't do things unless I confirm.

if $5.6B is protected by your index finger then you're gonna need kidnap insurance, and a really good pair of gloves.

It's not protected by the index finger at all. There is no fingerprint reader in a Yubikey. The only protection is that it requires physical access and can't be triggered from software.

If you're not buying the biometric ones, sure. Now you don't even need the gloves. Maybe kneecap armor instead.

Sigh. I forgot I posted this in a crypto-related thread.

I am not interested in cryptocurrencies. I am interested in people underthinking their risk profile.

The point is the attacker has to be near you and mot somewhere around the globe

My point is that the bigger mistake is an individual holding access secrets at all, irrespective of medium.

> The nice thing is that using the private key requires physical touch.

Yeah (not talking about crypto): yubikeys (or similar) are really sweet for that. I've use them for ssh / pushing / fetching from Git etc. I use them for 2FA to various services etc.

There are also similar devices where you enter a PIN and the PIN to register to a service the first time and then the PIN to auth are different. So you can't be tricked by mistake to register to a new service when you just want to auth (you could still be tricked to register to a service which ain't the one you think while registering, but never while auth'ing).

And yup I use that with AI all the time: my agents go inside a container or inside a VM (or both), and the damage it can do is very limited.

It's also possible to do passthrough of devices (GPU, USB, ...) to VMs: good stuff.

How would that help when your workstation is compromised? They can just steal your authentication the moment you log in through the password manager

It does help in that the secrets are not in plain-text, readable for any script you run. With 1Password, a process asks for the password and it gets transferred not through the filesystem but through IPC. 1Password shows a dialog: "Do you want iTerm to get your SSH key ABC123?"

In my thinking, this is more secure than plaintext in filesystem

If your system is compromised, it doesn't matter what you are using: the attacker will get the password for whatever secure thing you store your secrets in.

Sure, but is your system compromised because someone left a key in plaintext? Attack surface is finite and can be meaningfully reduced.

Maybe. Maybe not. It depends on the sophistication of the malware. Generally my impression is that these install-script type attacks cast a wide net. I would hazard a guess that they would not know how to even ask my 1Password for the keys. They are in an account they dont know, in a vault they dont know, and have a name they dont know

They don't need to ask 1Password for the keys, right? They can just take the kubectl auth once 1Password provided the key. But I would also bet any halfway competent script kiddy can vibecode credential stealing for the top 3 password managers these days. Heck, even open source red team stuff like this have it: https://github.com/efchatz/pandora

Not necessarily. defense in depth can help. At least forces an attacker to have to chain exploits, which although not impossible it makes it harder. Having root on a system doesn’t necessarily give you access to things that require touchid/yubikey/presence.

My secret is `4`. Is that ok? Do I still need to move it??

4 is fine, but only if you’re a certificate authority.

I use 'Solarwinds123'

as for ssh keys, you can generate your keypair in secure enclave and reuiqre touchId for every new ssh session. The private key never leaves the secure enclave.

Probably the better option instead of relying on a password manager.

It is a tradeoff. When using secure enclave, you need a second backup keypair in cold storage that needs to be secured.

Isn’t the password manager a prime target too?

you know most password managers have open sockets, or other channels to other local processes to interact with and allow stealing entries?

you know most tools like gcloud, bitwarden, etc store auth keys just in dotfiles too?

Local compromise is KO now, and we can't do shit on platforms like MacOs didn't research Linux recently

It’s true that they have their own attack surface but it’s not necessarily just open to the world.

Reply on news.ycombinator.com