The obvious next step is to plug this into a server and control it through USB over IP. Call it "remote, centrally controlled 2FA" and your manager will love it!
I don't really get how bolting the devices is a solution for enabling 2FA, unless the access console is also at the same location. But it would prevent 1) and 3).
Nice solution.
The risk is data exfiltration. A selfie in front of the SOCs giant screen wall; a compromised phone that keeps recording audio.
The problem is that a third-party SOC will generally need a way to connect to their customers' systems. Sometimes that gets properly implemented as a site-to-site VPN with isolated jump hosts and session recording. In other instances, the SOC gets to use normal employee VPN access, and usually a handful of VPN tokens.
And now you have a fun conflict: One customer insists that no mobile phones are carried inside the secure SOC area. Another uses a VPN solution that requires a smartphone (and, e.g. Duo Push) as the second factor. How do you satisfy both? You take a set of mobile phones, possibly add some measures to stop them from being used as recording devices, and bolt them to a table so they can't leave the secure area.
The 2FA services that allow >1 YubiKey are good, I can have a backup key locked up some place and use them as intended.
The fact that you can store copies effectively defeats the purpose of 2FA.
One of the reasons to have multiple YubiKeys is that if I lose one on the street I can just login to all my services with my backup key, disable the lost/stolen key, and buy and register a new key.
Whereas if someone got a hold of your TOTP secret, ehhh ... you might not necessarily know for a while.
> to plug this [Yubikey] into a server and control it through USB over IP.
Obviously multiple Yubikeys is the only real solution.
One reason to have multiple copies of the TOTP secret is to not be locked out of accounts should one lose their 2FA token. For example, if one has two copies of the TOTP secret, one of which is in a secure location, and one of which is used for daily purposes, as long as the secure location is reasonably secure, it's not much different than storing backup codes in that secure location.
I do agree with you that having multiple copies of the TOTP secret that can be lost and not noticed isn't a good idea though.
They should ideally support >1 TOTP authenticator if they don't intend to support U2F.
I don't want SMS as a backup option; I have deprecated SMS, it's old tech and needs to die along with telegrams.
Maybe The Google app has changed now, I have no idea. I’ve had much better luck storing TOTP in 1Password and Bitwarden - which allow you to sync across multiple platforms. So now device upgrades are a non-issue.
Most sites give you some static backup codes for TOTP - definitely store those somewhere safe, they can be a lifesaver.
Twitter and AWs only allowing one is just awful though.
Do most services that support such devices really only support a single key/device? Do they offer the same one-time recovery codes that are generally offered with TOTP (though the storage/security of such codes server-side is dubious), for the eventual failure of the Yubikey (not if, but when)? Surely a tiny hardware device reaching the end of its lifespan doesn't mean you lose access to your account.
I have personal accounts with Google, GitHub, GitLab, Facebook, and DropBox that use at least two of those four authenticators. I also have Login.gov (US government) and Gov.uk Verify (one of two UK government authentication systems, hooray for needless duplication)
Most of them offered one-time recovery codes which I hand wrote in a book of one-time recovery codes, but without fetching that book I can't tell you it was all of them.
At my previous job I used a physical authenticator with AWS and that was indeed restricted to just one authenticator, on the other hand there's an account "administrator" for that AWS account so if you lost your authenticator the admin can get you back in and I assume larger companies have multiple people in the administrator role.
The WebAuthn specification explicitly says that Relying Parties (ie web sites) should support multiple keys.
And yes, if you lose access to all methods of authentication in some cases you lose the account. I believe GitLab explicitly flagged their intent to act this way for accounts that don't pay them money, and I would prefer this. As I wrote back then, if it's not worth an hour of my time to somehow try to prove my identity to you after locking myself out of your service (which if I'm not paying you, it probably isn't), then I don't want it to be worth an hour of some social engineer's time to steal my account.
Of course, it depends what you want to defend against with your backup - this works fine for a broken OpenPGP smart card (;)) but in the event that it's lost or stolen.. well the best that can be said is that it gives you some window to create a revocation cert, login, and change the single registered FIDO device to a (third) newly provisioned one (or your second one, the backup, provisioned with a new key after logging in).
Or you could use a different method as your backup (IME if they only allow one they do at least also have backup codes, app-based, etc.) in order to login and change the device to the backup provisioned with a different key. (So it can be generated on the device in this case.)
Supporting multiple keys is a better solution.
Backup codes are not like passwords in at least two important ways:
* The site picks them, not you, so they're random nonsense different for each code, rather than inevitably being password1234 and being the same on Instagram, Twitter and your bank account.
* You don't need them usually, so there's no reason you'll have them to hand, which then makes it harder to steal them. Even for a social engineering attack, you increase the friction because now to help the attackers a user needs to go find their backup keys which is a hassle.
We've used https://rsc.io/2fa to share TOTP keys between multiple individuals. We store the secret key in a shared password store that's also behind a separate 2FA login.
For U2F, check out https://github.com/github/SoftU2F
WebAuthn / U2F are explicitly designed to allow multiple authenticators. The W3C WebAuthn spec. explicitly calls out that you should allow users to register more than one authenticator, and might want to provide a nice way for your users to label them, e.g. "Yubikey", "iPhone", "Greg's key" or whatever. Every site I've used that offers WebAuthn does this correctly except AWS and you'd have to take that up with Amazon.
Just match the code the user entered against all registered authenticators. Limit the number of authenticators to maybe 3-4 per account.
That isn't really an issue with TOTP either (if properly implemented), as each authenticator has a unique identifier and seed.
I've got multiple authenticators set up on a PayPal account. When logging in, I simply select which of the authenticators I want to use and enter the code it gives me.