-- You can't provision more than one security key. I want to provision a backup key.
-- You must have TOTP or text-message 2FA enabled in order to use a security key. But the very reason I want to use a security key is because I don't want to trust my phone!
As for limitation of one key, I use my Yubikeys with TOTP as well, so for services that don't support more than one security key, I store the same TOTP private key on both my security keys and get around it.
USB-C works fine with the Yubico authenticator app, IME. Using a Yubikey 5c.
Haven't used the lighting one, as I don't have an iPhone. Probably fine.
The one annoyance is that there's no USB-C + NFC key yet.
Edit: on my old phone I also used a USB-OTG (Micro-B male to A female) adapter with a normal Yubikey4, which worked (but was an ugly kludge).
Hashicorp vault has something like this to generate a root token. You can split your unseal key according to shamirs secret sharing. You can bring together a specified number of unseal key shards and generate a new root token with them. The app had endpoints to manage all this. You could create your own app with your own endpoints with similar functionality.
I don't think there are cryptographic primitives to give you this easily, without some trust logic baked into the app layer.
Do you have an example of such a system? I would be curious to read about the motivating use case.
IMO TOTP or even U2F have serious over the shoulder and grabby partner kinds of problems compared even to needing to type with semiprivacy.
Technically, in PAM, etc you could always add multiple rules.. But mostly this devolves into RBAC with separate roles so 1 type of admin does each step, but an absent admin is replaceable with another of the same type.
I tried to push a change/publish approach over a more traditional RBAC approach once, but it didn't fly.
To use TOTP then Alice and Bob have to contribute their shares to something, that something has to combine the shares to recover the key, and then generate the TOTP code for the current time, which it sends to S (or sends back to Alice and/or Bob who sends it to the server?), which knows the seed and generates the code for the current time, and checks to see if they match.
The question then is what handles the share combining? You'd need some sort of intermediate party that just receives shares and computes the TOTP code for sending to the server (directly or indirectly). Alice and Bob have to trust that this party will not keep the shares or keep the recovered code because then the entity could generate the TOTP code at will in the future without Alice or Bob's input.
It would probably make more sense to just have the server keep separate TOTP seeds for Alice and Bob, and authorizing requires Alice and Bob to both send their separate TOTP codes to the server.
Where things like secret sharing shine is when you have a secret that that S is not suppose to know persistently. For example, we use it at work for a database with sensitive data. The data is encrypted, with the key in non-paged RAM. When the server starts, a couple shareholders enter their shares, which reconstructs the key. If someone were to steal the server itself they would not get the key.
After that, I tried several examples from the man online man page [1], copying/pasting from Firefox to a terminal. Many of them failed, with errors like "oathtool: hex decoding of secret key failed".
To save others time...get your examples for copy/paste by doing "man oathtool" in another terminal and copying from there. The online manual has the dashes in arguments like "--totp" and "-w" rendered as Unicode minus signs (U+2212). Command line arguments need good old fashioned dash (U+002D).
There's an email address at the bottom of the page for reporting bugs, but my email client didn't like it. Sure enough, there are dashes in the email address which on the web page are Unicode minus signs, so had to grab it from the man page to send off the mail.
Maybe they're too lazy to do the work?
They're actively trying to discourage good practice?
There aren't any good excuses.
https://support.1password.com/one-time-passwords/#use-your-o...
I personally think the reason they require both to set up a security key is a user recovery issue. TOTP is highly reproducible and a security key is not. You can't back up your private key (by design). You just have to buy several and store them separately. I can encrypt my seed, put it in a QR code, and print as many copies as I want at no cost. If my backup Yubikey fails, I'm toast if I need recovery.
There are desktop and phone apps for it, which works great with nfc yubikeys on mobile.
There's plenty of others obviously, phishing is an infinite sea of crazy ideas, but that's a few huge ones gone.
The reason Security Keys (ie WebAuthn/U2F) doesn't get phished in this scenario is that the human's worthless opinion about whether this is the correct site isn't used by these technologies. Your WebAuthn credentials submitted to the utterly convincing phishing site fake-bank.example don't work for your real-bank.example login and the phishing fails.
Add TOTP, add security key, then delete the TOTP token from your phone.
At that point, the only copy of the TOTP secret is stored on Twitter's servers.
That's an interesting threat model that I don't hear very often. Can you expand on what threats you're trying to protect against? If you ever sign in to Twitter on your phone, you're trusting your phone with your Twitter account at least to some degree.
The main thing security keys protect against that TOTP doesn't is phishing.
And even if you are already signed in to everything and think you won't ever need to sign in on your phone again, the malware can force a logout of something, and you won't be able to know if it was just some software update or expiration that signed you out. So you'll sign in again, and the malware will intercept your security key.
I almost never use Twitter on my phone, and if I switched Twitter to depend on my Yubikey, I would stop using Twitter on my phone completely.
Is remote desktop compromise less likely than remote phone compromise? Phones tend to sandbox each app, so a single malicious or compromised app cannot take over your phone. Desktops on the other hand allow any app to do essentially anything on your computer. Accidentally open a malicious email attachment and you're done for. Generally I consider machine/phone compromise outside of my threat model.
Is security key theft less likely than phone theft? Also, phones generally require a password or fingerprint or face to unlock, while security keys generally do not (Yubico announced a fingerprint-protected one 18 days ago, but it's not available yet).
I bring my phone with me in lots of circumstances where I don't bring my security key, so yeah I think it's more likely to be lost/stolen.
Also, TOTP has a MITM problem that U2F/Webauthn doesn't have.