That's actually a really good idea, but I think it could cause problems for things like external numpads.

Maybe require the user to type a random combination of keys shown on the screen before enabling a given input device, instead of their own password?

> require the user to type a random combination of keys shown on the screen before enabling a given input device

If you could type it on any device, and you could guarantee that the OS could remember that device, I could see that being workable.

I would also worry about:

Ensuring that the keys shown bit is properly accessible to screen readers/braile devices, etc.

Ensuring that automation could authorise a device, or disable the prompt requirements

Ensuring that the OS actually remembered it. Plugging into different docks at home/work/conference room and having it prompt you to re-authorise your keyboard would drive people up the wall. eg: because during USB Enumeration the port numbers on your dock got switched, or they plugged the dock into the other side of their computer, or the Wireless USB controller is slow at starting up.

How to handle an unauthorised device when there's no other usable input devices. eg I started up my HTPC, and a few seconds later the IR receiver wakes up and is now marked as unauthorised - the device may not have a keyboard but that receiver appears as one. Or maybe I'm trying to fix a laptop and the on-board keyboard is broken, so how do I plug in a USB keyboard to get at the data on it (Maybe I can't reboot)

Some of these things might conflict with having such a lockout.

That doesn't stop a keyboard that is actually backdoored to execute payload sometime much later after setup.

Sure, but it's not intended to. It's to prevent a device from pretending to be a keyboard without any user's knowledge.

No, but it does stop you from getting pwned by a plasma ball.

I think it is a hard problem to solve BUT I think OSs should offer a compromise. That you are notified each time and can grant or deny. This should be an optional setting for those that want to easily add hardening (I think there's no excuse that linux distros don't have a "hardening" setting in their advanced or security settings).

I don't know the answer to this, so I'll ask. Can USB ports be programmed to only output voltage but not data? If so, this seems like a cool way to implement the above as you can have Deny, Access (power), Access (data) as options.

Grant/deny just leads to people clicking accept, you want something where the user has to choose what kind of device the plugged in and if it doesn't match what the device says it is then you reject the device or something.

On Linux GNOME already has USBGuard support btw.

> Grant/deny just leads to people clicking accept

I was imagining this being in some advanced setting with a "here be dragons" warning. Or even a bit more relaxed like Firefox's strict or custom tracking protection. It comes with warnings and I feel pretty confident to say that most users don't touch these settings.

> On Linux GNOME already has USBGuard support btw.

Yeah I know there are plenty of hardening tools out there, but I was suggesting that they come pre-installed. There's so much bloatware on most systems these days that this seems minor. Or maybe someone could put together a bundling script to make adding all this (e.g. USBGuard + Fail2Ban + Faillock + Firejail + etc) easy to install and configure. I'm not aware of any such tool. But maybe even an Ansible script could go a long way.

> I was imagining this being in some advanced setting ... most users don't touch these settings

That just leaves most users unprotected.

> I was suggesting that they come pre-installed

GNOME's support for USBGuard is installed by default, but USBGuard itself may not be depending on the distro. Agreed that it and other security/safety/robustness (for eg SMART disk warnings need to be supported) stuff (should be enabled by default. GNOME should use Flatpak-style sandboxing for natively installed apps too.

> That just leaves most users unprotected.

Aren't these users already unprotected? I don't think this is a security concern for most people and turning on by default would frustrate them more. It'd be like shipping Firefox or Chrome with NoScript on my default. Sure, more protection, but it would turn away more people than it would pull in. Better as optional.

Firefox is ratcheting up the tracking protection for normal users and GNOME enabled Thunderbolt protection by default, so there is definitely precedent for protecting regular users too. Also with the rise of stalkerware, normal users are definitely targets too. I think the interface I proposed would be reasonable enough for most people and you could make it easy to turn off with the right UX.

grant/deny can be easily overcome by malicious input device with high pass rate

Surely not if the device has no access to the machine until after you press grant.

OK, good point

Android already does this but from the other side. I assume iPhone as well. When you plug in a cable it only does power until explicitly allowed to move data as well.

For those wondering, there is an easy defense against this on Linux, USBGuard (https://usbguard.github.io/)

RHEL7+ include USBGuard as part of the standard repo [0]

[0] https://access.redhat.com/documentation/en-us/red_hat_enterp...

This isn't very practical as a defense. You can't configure it to ban keyboards, because you still need a keyboard, and you might need to swap keyboards if your original one breaks.

That's not correct, it can block and does block USB keyboards. If your main keyboard was totally dead and you needed to whilelist a replacement keyboard you'd do so by booting into single-user mode.

How do you distinguish between a new keyboard and a bad USB cable that gets wiggled a bit?

check the Device ID, if its the same as the one that was in the port a second ago it the same.

What about spoofing?

An attacker can lie about what their device id is

How would it know the right device id to spoof? (Definitely doable in a MITM scenario, but more complicated in others).

Pick one of the most popular keyboards used by your target and reuse it. That's how I'd do it. It's not going to get everyone but I think it's a legitimate approach.

The alternative methods looking at the time between keystrokes seems more reliable.

Keystroke delay based heuristic is just naive, all that means is that the attack needs to happen on an idle system.

In an ideal world, vendors would actually populate the serial number field with a number that's at least semi-random.

On this computer, only the USB-C HDMI adapter and the fingerprint reader have a serial number that looks random :-(

Don't yubikeys register themselves as keyboards? You can definitely tap the button to get a code typed into any input field.

By default, yes. You can disable the "long-press to send password" feature.

(I kept triggering it by accident, and disabled it.)