If you are getting powned by running random executables found on usb drives, passkeys aren’t going to save you. Same if the social engineering is going to get you to install random executables.
If you're getting pwned a physical Security Key still means bad guys don't have the actual credential (there's no way to get that), and they have to work relatively hard to even create a situation where maybe you to let them use the credential you do have (inside the Security Key) while they're in position to exploit you.
These devices want a physical interaction (this is called "User present") for most operations, typically signified by having a push button or contact sensor, so the attacker needs to have a proof of identity ready to sign, send that over - then persuade the user to push the button or whatever. It's not that difficult but it's one more step and if that doesn't work you wasted your shot.
All your 2FA apps, token, security keys, certificates and what not only protect the authentication (and in the case of online banking, a few other actions like transferring money). After that, a single bearer token authenticates each request. If your endpoint is compromised, the attackers will simply steal the bearer token after you authenticate.
That's true, but in terms of system design you definitely should ask to see the proof of identity again during unusual transactions and not just that bearer token - for example attempts to add or remove 2FA should need that extra step, as well as say high value financial transactions or irreversible system changes.
I think the claim is that plugging in the USB device is enough. If people needed to try running an executable from the device, some devices would still be compromised, but with lower frequency. I don't know exactly what happens. Automatically-triggered 'driver' install that is actually malware? Presenting as a keyboard and typing commands? Low-level cracks in the OS USB stack?
It feels to me more like OSes ought to be more secure. But USB devices are extremely convenient.
Still fits "It feels to me more like OSes ought to be more secure."
New USB-HID keyboard? Ask it to input a sequence shown on screen to gain trust.
Though USB could be better too; having unique gadget serial numbers would help a lot. Matching by vendor:product at least means the duplicate-gadget attack would need to be targeted.
But, haven’t there been bugs where operating systems will auto run some executable as soon as the USB is plugged in? So, just to be paranoid, I’d classify just plugging the thing in as “running random executables.” At least as a non-security guy.
I wonder if anyone has tried going to a local staples or bestbuy something, and slipping the person at the register a bribe… “if anyone from so-and-so corp buys a flash drive here, put this one in their bag instead.”
Anyway, best to just put glue in the USB ports I guess.
Even if the OS doesn't have any bad security practices and doesn't do this, there is a very simple way to execute code from an USB stick: the USB stick pretends it's a USB keyboard and starts sending input to access a terminal. As long as the computer is unlocked, this will work, and will easily get full local user access, even defeating UAT or similar measures. It can then make itself persistent by "typing in" a malicious script, and going further from there.
> there is a very simple way to execute code from an USB stick: the USB stick pretends it's a USB keyboard and starts sending input to access a terminal
Good systems these days won't accept such a "keyboard" until it's approved by the user.
Which systems ask before allowing you to use a keyboard you just plugged in over USB? Windows, Ubuntu, Fedora certainly don't, at least not by default.
Mine. Not asking whoever happens to have local physical access interactively, strictly speaking, as that just papers over one of the problems; but controlling what Human Input Devices are allowed when plugged in, by applying rules (keyable on various device parameters) set up by the administrator.
Working thus far on NetBSD, FreeBSD, and Linux. OpenBSD to come when I can actually get it to successfully install on the hardware that I have.
In principle there's no reason that X11 servers or Wayland systems cannot similarly provide find-grained control over auto-configuration instead of a just-automatically-merge-all-input-devices approach.
It's not an interactive approval process, remember. It's a ruleset-matching process. There's not really a chicken-and-egg problem where one builds up from nothing by interactively approving things at device insertion time using a keyboard, here. One does not have to begin with nothing, and one does not necessarily need to have any keyboard plugged in to the machine to adjust the ruleset.
The first possible approach is to start off with a non-empty ruleset that simply uses the "old model" (q.v.) and then switch to "opt-in" before commissioning the machine.
The second possible approach is to configure the rules from empty having logged in via the network (or a serial terminal).
The third possible approach is actually the same answer that you are envisaging for the laptop. On the laptop you "know" where the USB builtin keyboard will appear, and you start off having a rule that exactly matches it. If there's a "known" keyboard that comes "in the box" with some other type of machine, you preconfigure for that whatever it is. You can loosen it to matching everything on one specific bus, or the specific vendor/product of the supplied keyboard wherever it may be plugged in, or some such, according to what is "known" about the system; and then tighten the ruleset before commissioning the machine, as before.
The fourth possible approach is to take the boot DASD out, add it to another machine, and change the rules with that machine.
The fifth possible approach is for there to be a step that is part of installation that enumerates what is present at installation time and sets up appropriate rules for it.
Out of curiosity, how does that work if this is the only input method connected? Or is this only shown if you have another keyboard (and/or mouse) already connected.
An automated van that has roughly regular routes but goes slightly out of its way to pick up/drop off people would be a good middle ground between taxis and buses —- not unlike Jeepnys in the Philippines.
No, it is a terrible middle ground. They work only for people who are okay with being late to a meeting once in a while, or people who are okay with arriving far too early and then waiting once they get there. People who value their time want something predictable so they can arrange their time around things they understand.
Vegas is also good for many other reasons: year round good weather, lots of tourists in need of taxi services, too hot to walk, too drunk to drive, etc…
I remember once going on the way back a work trip on a whim, and regretting not checking that the weather was >100 degrees. That step outside was an oven.
It's also kind of far and inconvenient to get to. It's like the inverse of those shuttles that take you from the arrivals loop of the airport to the ass end of the casino loading dock of your hotel (and 10 other hotels. So, unlike Uber, not even remotely worth it).
Interestingly Vegas is the only place I will use a cab over Uber or Lyft or (preferably) Waymo. Using the Curb app to pay electronically you avoid most of the BS with cash and "their card machine being broken", and once you've done it a few times you know the actual correct routes between places.
I've been building Crossabble (https://crossabble.com/) a free and fun weekly web word game. Feedback welcome!
The game is mostly done, so I'm now focused on tooling to make it easier for me to craft each week's puzzle. I'm solving some interesting graph and optimizations problems
