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 remember a story about how our (third party) security operations center doesn’t allow phones on the floor, but most of its customers use Duo Push. So there is a table in the middle of the floor with all the 2FA phones bolted to it.
The threat actors are SOC employees or visitors who might (maliciously or unwittingly) use their smartphones to record sensitive data.
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.
Threat is that the mobile devices could be used to 1) photograph proprietary systems, 2) exfil data over mobile networks or potentially introduce 3) malware via usb ports.
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).
As long as the table is bolted to the floor, you're replacing posession (of a phone) factor, with location (in SOC) factor. Keeps both client happy, and security architect sleeping soundly.
Considering many services only allow one YubiKey or only one TOTP authenticator ... I might actually need a short term solution like this to beat the 2FA on those services. Otherwise what happens if I lose my key on the road?
The 2FA services that allow >1 YubiKey are good, I can have a backup key locked up some place and use them as intended.
You could generate the key(s) on a (airgapped, if so inclined) computer, push to multiple Yubikeys (though other brands are available, let's not let it become a 'google') and then delete the private key(s) from computer.
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.)
Some policies will disable your Yubikey/U2F key if it goes unused for N days. Usually low enough that it's annoying to keep a backup key.
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.
With TOTP it's very understandable to limit you to one authenticator as each additional authenticator makes it easier to attack you (meaningfully more guessed codes are now correct at any moment) and the UX is awful because there's no good way to discern one TOTP authenticator from another.
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.
> ... each additional authenticator makes it easier to attack you (meaningfully more guessed codes are now correct at any moment) ...
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.
Holy crap. I've avoided buying a U2F/FIDO2 device (eg. YubiKey) for a few years thus far, as I'm "happy enough" with TOTP. I know the differences in terms of implementation/security, but not enough services even offer TOTP, let alone the U2F/FIDO2 protocols. It's not worth the investment right now for how generally unsupported it is.
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 a pair of hardware FIDO authenticators, and my phone and laptop are both platform authenticators.
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.
I’m pretty sure every site I’ve setup to do TOTP only allowed one authenticator. I got burned using Google Authenticator when I had to replace my phone, because there was no way to transfer the auth data to a new phone.
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.
Those backup keys defeat the entire purpose of 2FA and are like storing passwords in plain text. It only takes 1, maybe 2 of those codes for an attacker to add another security key to your account for future unlimited access.
Supporting multiple keys is a good idea but it solves a different problem. People want peace of mind.
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.
I think the parent’s point is that if you’re going to allow backup codes you might as well just add “second password” as a form of 2FA and enforce some basic complexity requirements.
It would be better to use a software TOTP authenticator with backups. You could also store multiple encrypted copies of the TOTP secret encrypted with different Yubikeys. I don't know if there's any software that does this automatically and momentarily decrypts the TOTP secret into a secure memory location when you need it. That preserves... most of the benefit of 2fa.
"better" is a strange word to use when discussing security, everyone's situation is different™. You're making a set of trade-offs between availability (backups) and confidentiality (only using hardware tokens which are tamper evident) which absolutely do not generalize to every case.
I'm saying if your hardware token is plugged into a machine that you connect to with USB-over-IP your hardware token is basically security theater and your actual security is whatever secret you use to protect the machine the token is plugged into. So if you're worried about availability but want something like 2fa software TOTP secrets make a better tradeoff.
Storing copies of a TOTP secret is as good as just having 2 high-entropy passwords and saving multiple copies of one of them in clear text, which is not more secure than having 2 high-entropy passwords and not storing them anywhere, and which is equivalent to just 1 doubly-high-entropy password not stored anywhere.
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.
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.
There are these RSA-brand tokens that show a new TOTP number every few minutes. Occasionally people find an unsecured webcam pointed at one of those somewhere on the internet...
