-- 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!
What is it with this bullshit practice of requiring TOTP/SMS setup first before using security keys! I've seen this all over the place, seemingly copied from all the existing ones. Basically they're saying, you must have a less secure 2FA before using a more secure one. Even github does this circus show but at least it lets you register two keys. So what I do is to setup TOTP, add two keys and then remove the TOTP on 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.
Hah...before you commented, I searched to see if there were any decent TOTP command line tools, found that, found that it's available via Homebrew ("brew install oath-toolkit"), and installed it.
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.
Hmmm...so let's say the server, S, knows a TOTP seed, and that seed is shared with Alice and Bob via Shamir's secret sharing method.
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.
AFAIK the simpler option has been 16 character passwords entered by 2 people physically at the same console.
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.
I am aware of the principle. But why would the TOTP seed be encrypted by multiple parties versus a system requiring k of n users to respond with a TOTP response or something else?
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.
I wish I could understand why platforms are still only allowing one hardware key, especially a platform like Twitter with a sizable base of advanced users.
Also 1password has built in support for TOTP codes. The killer feature is that must have saved me ~hours is that it automatically copies the TOTP code to my clipboard after login
As @regecks says below, you only need to add it temporarily and then delete the app. I agree they need the ability to have multiple keys.
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.
Technically yes, but the main tricks for phishing OTP codes from phones now don't work with those apps, the current ones involve getting people to install an app and getting them to give the app SMS permissions, which there isn't a permission for getting data from ubikey apps unless they go through the phone's storage which is a problem encryption and fingerprint scanners can fix. And calling someone and telling them you accidentally put their number into a site an are trying to recover their account so could you please read me the number you get texted, which doesn't work for UBIKey since you know exactly what that code is for and they can't have been the previous owner of your phone number or accidentally sign you up to that.
There's plenty of others obviously, phishing is an infinite sea of crazy ideas, but that's a few huge ones gone.
No. There are ready to go out of the box proxy tools that rely only on you thinking this proxy is really the site you wanted, and then your TOTP, SMS message, any of these third rate second factors get phished.
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.
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.
You don't necessarily login to Twitter on the phone (I don't for instance). Even if you did, your login credentials are considered more sensitive data than the session cookie you get after you're signed in. As with the Twitter app, the window of time in which your login creds are in memory is short. With a TOTP app holding your private key around, you basically have half the credential available at all times (unless of course the TOTP app makes use of the mobile platform's hardware chip to encrypt the private key when app is not in use).
Yes, but assuming your phone is compromised, it can intercept the password and security key as you sign in, and take over your Twitter account. In fact if you use your security key to sign in to anything on your phone, the phone malware can use it to access any account linked to the security key (assuming the malware has your password). So even if you don't sign in to Twitter on your phone you're still vulnerable.
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 have never used my Yubikey with my phone for any application, I don't even know if it works, and I see no reason why I would start. I almost never use Twitter on my phone and if I switched Twitter to my Yubikey, I would never use it on my phone.
TOTP isn't vulnerable to porting numbers, so you're safe from that threat.
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).
-- 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!