I hate that people say that.

By adding some security (protecting against some threat) to another security (protecting against same threat) you gain no security, after all: 1+1=1 in binary, so security is binary in this way as well.

By protecting the same thing with two different security mechanisms, you have multiplication, and in binary 1×0=0 so security is binary in this way.

And so on.

Security is about identifying threat-actors and devising cost-based challenges that exceed the value to others of compromise. In that way, it is absolutely a binary thing -- you are either secure from those specific threat-actors or you are not.

It's a real problem that without perfect knowledge, you don't actually know if you are secure from those threat-actors: Someone can discover a cool factorisation trick, or your computer might make weird noises when multiplying certain numbers, or it might allow authenticated users faster responses than unauthenticated ones. Threat-modelling in the face of those kinds of thing is nearly impossible, but even against basic stuff (the stuff we already know) it can be really hard. For these reasons and more, weakening some security in what you may perceive as a small way can actually be absolutely catastrophic to the security against the intended threat-model. So don't do that: Start from the other side, decide what you're trying to protect and from whom, and convince yourself that they really can't gain anything with what they've got.

Script kiddies using a ten year old version of metasploit? The finger is probably safe for all the reasons you're thinking, but if they find a way in, someone else is going to strace/gdb/dtruss all the things and find you've got a lot of secrets in RAM - if any of those belong to an even higher-value target, you can bet that is automatically harvested, collected, and shipped back to "home base" for use.

> This mechanism is more secure than no 2FA,

You can't meaningfully say more or less secure without saying who the threat-model is.

For threats I worry about, this is much less secure. I also believe that's true for most yubikey users, including the ones with the technical ability to do something like this.

> the thing will move and you’ll hopefully realise you’re haxx’d.

If the yubikey cannot be triggered by my PC because there isn't a wire connecting the two together, then there is zero risk from a remote attacker who does have access to my PC -- unless you believe the airgap grants you nothing in the first place.

I mean, I hope the airgap means something, but I don't hope that I will always be awake and in front of the finger paying attention to its gyrations and undulations.

If your Yubikey had a PIN terminal, it could treat the entry on its own PIN terminal as presence indication, but it just discerns the PIN via CTAP from the host computer and that might be caused remotely.

1) I really wanted to give out the free advice that people should plug their yubikeys into their monitors. Get two so you can have one in the monitor and one in the laptop (or laptop bag). Also, you don't need a USB c key for the monitor.

2) there's the specific question of "what is the surface area of attack?" With a yubikey, you limit that surface to "people who have physical access to your device"

I didn't make the case that security is binary. I simply pointed out that they are severely compromising their security posture by re adding remote users as a surface of attack.

If someone compromises their machine and watches what steps they take to access eg a production network, the attacker will trivially see the yubikey being triggered. They don't need to know what it is or why it's being run. They'll just know that after you ssh you run this script.