This sort of defeats the idea of 2FA, doesn't it? If it's implemented as a software service on the same device, it's (well theoretically at least) hackable at the same time as the device itself. The 2 factors from 2FA are both accessible to an attacker at the same time, so you effectively have just a single factor auth.
It does, but there's actually a way to do this (ie. u2f without having to buy another device) in a safe way, by using the TPM available on most computers: https://github.com/psanford/tpm-fido
Unfortunately without additional hardware support it's hard to tie TPM FIDO to physical user presence, which means compromising the system doesn't give you access to the secrets but does let you sign as many challenges as you want without user involvement.
Realistically speaking if your machine is compromised it's effectively game over. If you're signing into services on a daily basis an attacker wouldn't have to wait long to piggy back off a legitimate request. The chances that you catch the compromise before that happens is slim.
By the way, I like that tpm-fido is using uhid instead of USB/IP, because USB/IP doesn't have any security and authentication. At least we can restrict what user can create uhid host process etc.
It's still a second factor, just one that isn't as isolated as separate physical hardware. It's certainly more secure than a single password, while still giving the user absolute control over it.
I can see this being very useful for accounts which are effectively throwaway, but they still force you to 2FA. The same is true of TOTP generators.
By that, totp isn't a second factor either.. it's something you know.
If it's something you have, that would be the same with passwords.. I don't know them..
It depends on how you use passwords and TOTP. I think the expectation is that busy people have a generator on their phone so it is know your password and have your phone.
Of course if you are like me and keep your TOTP secret in your password manager than it is basically the same factor as a password.
TOTP is a second factor because you can't store it in your mind (and therefore it's not something you know, but something you have to have). You could defeat that using this virtual FIDO project or by storing the secret in readable format in a password manager that itself can be unlocked with your knowledge, but if we're just trying to find ways to use factors in a way that makes them useless, you can also just store them in a pastebin, it's free and all you need on any computer is to just visit your paste url!
I store both passwords and 2FA in an automated software. 2FA seeds can be exported (eg. when moving to a new phone).
the categorization makes some minimal sense, but basically any additional not-identical "factor" is additional security (though there's obviously a diminishing return because of the complexity-vs-security trade off).
> I store both passwords and 2FA in an automated software.
This effectively reduces the 2nd factor to the first, and indeed produces the diminishing return. It's sufficient to hack one system using one method and you compromise both defenses.
The point behind 2nd factor is to provide a second, *independent* layer of protection that would need to be compromised using an entirely different attack.
In the case of the FIDO2 dongles including the Yubikeys the secret isn't even stored on your system, but on the device itself that doesn't even disclose it to your connected system.
The e-mail thing is a bit silly; sure, if someone leaks your password you're safe but if your device is compromised there is good chance attacker have access to your e-mail too
Actually if your PC is compromised, then bad guy can exploit even hardware Yubi, because Yubikey lacks any screen, only button.
Adversary can intercept your login in MITM style, authorize themselves on other machine, just using your machine as proxy, and website you tried to login to would just display error "can't authenticate, try again".
And thangs to fact that key lacks display, attacker can event authenticate to different site, than you are authenticating now.
Trezor is way better device here:
> Phishing protection with on-screen verification. Trezor always displays the URL of the website the user wants to log in to, and what exactly is going to be authorized; therefore it is possible to verify that what was sent to the device is what is expected.
I'm a little confused here, but I thought 2fa was a combination of something I know (A password) and something I have (A authenticator). So a attacker getting access to your computer is same as them getting access to your authenticator?
Or do you mean that this leaves the secrets vulnerable to spyware and stuff? Cause in that case as the other comment says, one could use the TPM.
A good example here is 1Password, which stores passwords and also allows storing TOTP.
Which means the something I know is stored in the same places as something I have. Granted it is protected by encryption, and another password, but it definitely increases the attack surface.
If the computer is compromised it becomes much more possible to get access to both of these items than if it was a security key, physical authenticator or even on a different device.
Partially, but this still blocks many attacks that password alone wouldn't.
I always think of 2FA as insurance against password theft/leaks. If users don't practice good password practices and use the same password for multiple accounts, for example, when ${next web site to be hacked} leaks all plaintext passwords, you can't just turn around and use that password to access ${another site where I used the same password but have 2FA enabled}. Or I'm logging in to a site from someone else's computer and they have a keylogger. [Obviously this virtual 2FA device wouldn't let me log in in that scenario--but in general, this is another case where the 2FA doesn't have to be rock solid, it just needs to exist if you captured my keystrokes.]
A direct attack on my workstation to steal my virtual 2FA device and my passwords isn't protected by this virtual 2FA device, but that's low in my list of worries overall for people's account security.
To reiterate after giving it a bit more thought, this actually could be very useful if combined with fingerprint or facial detection as approval method - a bit like what Apple is now doing with passkeys, but will work with many more services out-of-box...
Nice! I'm the author of tpm-fido[1] which is similar to this but with some different goals. It looks like you've implemented ctap2, which has been on my todo list for tpm-fido (we currently use the ctap1 which works fine but doesn't support newer features used for passkeys/passwordless logins). Great to see other independent implementations!
The question is often asked: isn't this less secure than a physical key or touch-id? The answer is yes, but only marginally. If you have no other access to a FIDO authenticator, using a soft authenticator will still be much better than using SMS,TOTP, or Push. Phishing is the most likely way 2fa will fail you, and this is still phishing resistant.
But passkeys are real and you can essentially use them today! The Android/Chrome integration is already quite good. The Chrome/iOS interaction works but is less smooth right now. That's going to get worked out quite quickly so if you have the option to use passkeys you should!
This is my problem with fido/yubikey's and WebAuthN, etc. Somehow Fido and Yubikey have become intermixed and conflated. Like kleenex - one brand of facial tissue has become the common name for something that is or should be a commodity product. The top picks for me when I search for "yubikey" on amazon are all ~$55 USD. When I search for "fido2" the top picks are ~$24 USD.
This article is about Yubikeys. Or is it. The project itself is "virtual-fido".
I am sure that it is in Yubico's best interest to promote Yubikeys. And for the enterprise this is probably good. But in my opinion it is a barrier to the adoption of fido. Which is unfortunate.
I wonder if there is a way to use an iPhone or Android as a Yubikey. Oops, I mean Fido device. Anyone have an idea of how to do that? It seems like getting this to run on an Android would be significantly more functional (no extra device) and cheaper.
> I wonder if there is a way to use an iPhone or Android as a Yubikey. Oops, I mean Fido device. Anyone have an idea of how to do that? It seems like getting this to run on an Android would be significantly more functional (no extra device) and cheaper.
Krypt.co. It's been bought and turned into a commercial service but their free platform continues to work without issue. Obviously you shouldn't use this as your own way to authenticate and newer standards aren't supported, but I use it every day for my self hosted services (put everything behind Apache OIDC + Keycloak so I don't even need to set a separate password on my self hosted stuff anymore!)
That's essentially what passkeys are: a consumer-friendly name for on-device FIDO keys you can use over webauthn, along with (in the apple/google/Microsoft case) a mechanism for syncing/backup/recovery provided by your platform account provider. The keys are still backed by hardware, but instead of an external key it uses the internal platform security module (TPM, Secure Enclave, etc.)
You can use your phone without the syncing part to authenticate other device through a mix of a QR code, a tunnel server, and Bluetooth.
> Didn’t RTFA as I know the algorithm is just one line of python using built-in libraries
Time-based OTP (TOTP), which is what Google Authenticator implements, is not the same as FIDO U2F. They use different underlying mechanisms and have different security properties.
TOTP relies on a shared secret key to generate a matching code on client & server. FIDO U2F uses a challenge-response protocol and incorporates the domain of the requesting website (the domain as verified by TLS certificate) into the challenge to ensure that the response is _only_ valid when it was requested directly from the correct website. This prevents phishing attacks, which TOTP does not.
> I wonder if there is a way to use an iPhone or Android as a Yubikey. Oops, I mean Fido device.
Yes / sort of. Both systems provide WebAuthn in their native browser, if they have a suitable place to store the private keys, and a way to authenticate the user. On my Pixel 2 it was the fingerprint sensor, on some iPhones I believe it uses FaceID.
In WebAuthn terms this is a platform authenticator, it also provides both factors so you can (but as far as I know no popular sites do) have usernameless one click login, you say I want to log in, your phone sees you have exactly one identity on this site, it provides credentials for that identity, you are now logged in.
The phones also have the same behaviour for apps via their API. This is masked so that rather than being bound to a DNS name like WebAuthn, it's bound to some app identifier, which you "own" on that platform, so a dubious "Better Flashlight" app can't authenticate as the "My Neat App" on the same phone. On the backend you'd adjust your code so that it can handle e.g. SHA256("myneatapp.example") for the web site but also SOME_APPLE_ID for the iPhone app and SOME_GOOGLE_ID for Android.
I've seen this behaviour (not advertised as such) in several apps in the last 2-3 years. The NHS app I use to order routine medication refills is an example. Tap the app, it asks me to log in, presenting a fingerprint symbol, I touch the symbol (this Pixel 6 has the sensor under the glass, I don't love that but I guess the UI is more obvious). Then I follow the exact same UI as if I'd done all the auth steps with fiddly email addresses and passwords.
[Edited to add]
Ooh, bonus feature. If you have Google everything you can literally use an Android phone as a Security Key on your desktop/laptop PC. Chrome sees a web site asked for WebAuthn, sees there's no Security Key plugged into any USB ports, it calls Google, Google sees you have an Android Phone on this account which can do WebAuthn, tells the desktop Chrome about that phone, the desktop does a Bluetooth beacon, "Hey, anybody around here called "tialaramex's Phone" ? Hit me back." If it can see your phone, it proves to Google that it saw your phone, and then the phone lights up with the details of the login you are attempting on the PC and you can authenticate to your phone in the usual way to approve it. Very complicated technically, but the UX is pretty reasonable.
The Bluetooth step is there to help prevent attackers spamming you with login attempts, they would need to be within Bluetooth range of the phone to make that work, so, if that happened you could have them escorted off the property/ arrested/ shot as seems appropriate.
I think this is really cool and a smart way to approach this problem. That being said, the physical isolation of the YubiKey is what makes it useful. Having to physically press a button is the real isolating factor, the interaction is physical and not determined by a piece of software.
Imo that it's not phishable and that there is no secret on the target server is even more useful in practice. And both those properties don't require physical isolation.
To nitpick: s/there is no secret on the target server/the target server never sees the secret/
With proper password storage the target server never keeps the password. It course that is difficult to verify. With U2F the secret can't store a secret they can't see.
Every year or so I try to figure out if a 2fa device practically has sufficient support that using it would improve my security. The answer has always been no.
No 2fa device has sufficient support that it could increase the security of my 1password account, which I use on Linux and Android. No 2fa device has sufficient support that it could be used to unlock the lockscreen of any of my devices either.
Edit: There is a way to use a Yubikey to decrypt Linux full-disk encryption. It relies on an abandoned personal GitHub project. Sounds fun, but not sufficiently secure it's worth spending more than $100 to allegedly improve my security with it.
Your phrasing is odd. 2FA devices do not support websites. Websites support 2FA options. The problem isn't 2FA devices, but services not supporting 2FA. U2F/FIDO are standard at this point and many tech-related services support them; certainly, effectively all 2FA devices support them.
2FA is redundant for unlocking physical devices. Access to the device itself is already a second factor.
The point of 2FA is that someone MUST physically take something from you to gain access, which greatly limits attack vectors. If you use 2FA properly, the only thing you need to worry about for account security is whether you still have your 2FA key on you.
Yes, but not for anything where keeping the SSH private key more secure than my AWS/DigitalOcean credentials would be useful. And I store those credentials in 1Password, which doesn't have a sufficiently mature integration with Yubikey on Linux or Android.
I've found the Yubikey to be an incredibly easy way to do 2FA. I use a usb-c nano version and it pretty much never leaves my mac (and the mac never leaves me). I've found it faster to do 2FA on a large number of tech websites. Just touch the key and you're done.
I know 1Password can fill TOTP for you, but I like having my security spread across 1Password and Yubikey. In the unlikely event 1Password gets compromised they still need physical access to my computer.
I don't log onto the mac with Yubikey and it has full-disk encryption turned on, so I'm pretty happy with the attack surface.
Both yubikeys are configured to enter the same impossible to memorize password on a press to unlock 1Password, hid mode is supported by every device with a USB ports.
I also use them as an otp second factor when a site requires it.
Finally, they are configured with a x509 certificate that I use as my ssh keys. I generate one key per devices that way the secret never leaves it and I require a pin to unlock the key. For convenience, I use an ssh agent to cache the pin
I could also use them for pgp signature and encryption but I have no use case for that.
How do you configure Yubikey to enter password for unlocking 1password? Is this a Yubikey feature or 1password feature? Does this also work with mobile devices (phones)?
That is the hid mode parent is mentionning.
With ykman you can configure the Yubikey to simulate being a USB keyboard (Human Interface Device) and then "type" a static password. The default setting is to type a Yubico specific OTP that can be checked by calling an API. The issue with the static password is that anybody getting near the yubikey with a device having a USB port can steal the password in seconds.
And any accidental button-press while in a chat-app or website will leak your password. I've seen many yubikey otp's accidentally pasted into irc, if you set it to password, you just posted that. I'd never recommend using that mode.
Not sure if this answers your question, but you can use a Yubikey for FIDO2 on iOS with any iOS device with a USB port, or use the camera connection kit to make one on a Lightning port device.
Source: I was curious, so I used a camera connection kit to login to Okta with a Yubikey as my MFA last month.
This is definitely true but honestly I'd love more websites to switch everything around and use a password for the optional second factor.
Many messenger apps already do something like this (using your phone numbers as a first factor and using an optional password for account protection) and IMO the login flow is much easier for services that I don't care about.
Let me register and login with WebAuthn alone and I'll be very happy. You can even use the same logic you're already using for password resets, just re-enroll the FIDO key when someone clicks "I can't log in" and proces access to their email account. Immune to credential stuffing and many other digital attacks that can happen from the other side of the world while you're asleep!
Not quite. A second factor would allow me to reduce the complexity of my password while retaining the same level of security.
Without that the only benefit of a Yubikey over a strong password saved in a password manager is phishing protection, which I'm not willing to pay that amount of money for.
If you believe yourself essentially immune to phishing and password leakage, I don't think that you are very likely to be convinced that you should buy a Yubikey.
The place where they shine is when you have already acknowledged that you want (or have been forced by your employer to use) 2FA.
> Malware on a device where I'm logged into the service can use that authenticated session to access all the things I want protected.
Any well-secured service should protect critical actions with 2fa. “oh, are you sure you want to transfer all your funds? Please re-authenticate first”
So if your device is compromised, the attacker could trick you into entering 2FA for some minor action while it actually is transferring all your funds.
If your PC or smartphone is compromised nothing will prevent you from losing control of your accounts.
Yes, that is what I was trying to point out. With Yubikey or other 2FA devices you can not see the transaction details of what are you signing unless the device has a screen so a screenless device does not protect much more than this virtual yubikey.
Sure: Enough support so that my life becomes sufficiently easier or more secure to be worth the cost.
I know that's a bit wishy-washy, but for example I think I could replace my memorized 1password password with something longer if I never had to enter it from memory, which would only be the case if I could use the Yubikey on all my devices.
I use a yubikey with x509 cert and PIN for local auth to my Mac, and I use it for FIDO2 MFA everywhere that supports it, which includes my email account. That makes my email credentials radically more resistant to phishing, which is huge given that email is part of the recovery story for every other account.
If those aren’t enough, I guess yubikeys aren’t the right call for your threat model, which is fine.
I'd love to have that setup. The only problem is insufficiently mature support for the devices I use, Linux and Android. As I mentioned in an edit Yubikey local auth on Linux relies on a personal GitHub project abandoned years ago.
Bah, everything the GP described works perfectly in Linux. Yubikey local auth isn't just one Yubikey specific project. The Yubikey implements a fuckload of open protocols, the vast majority of which work perfectly in Linux.
Want local authentication? pam_u2f, pam_gpg, pam_x509 are all maintained.
The other person who replied to this seems to have gotten up on the wrong side of the bed, but the core of their suggestion is one I’d likewise recommend. I’m doing the yubikey local auth using the yubikey’s PIV applet, which holds standard x509 certs that can be used via pkcs11.
Mobile access is one of the reasons I hope a near term next gen iPhone has USB-C support directly. The lightning / usbc yubikey dongle is just too unwieldy in my experience.
You can use Yubikeys(most of them, the cheapest ones don't have that feature IIRC) as smartcards in addition to other features.
You can use smartcard in linux as both GPG key, and SSH key (via GPG SSH agent).
Which means leaking your private key for SSH is essentially impossible, as key can be generated on device which means it never leaves it, even if your machine gets compromised
I love the Yubikey even if it only locks down a few important accounts. For me, that's Google Accounts and Microsoft Accounts. These are the accounts I worry about this most because they are linked to so many other things.
I wish 1Password offered a high security, security key ONLY mode.
The thing that trips me up is the ability to make backups in the event it is lost/stolen. Seemingly not all services allow registering an additional key, and even if they do, the practicalities of juggling redundant fobs would be cumbersome.
> Seemingly not all services allow registering an additional key
I’ve only ever encountered that braindead design with AWS, every other place allows multiple keys.
And I can’t say I find multiple keys cumbersome, it’s simply the same procedure again: Click add, insert key and tap the button. Just twice instead of once.
Specifically, I want a backup key off-site. Anytime I enroll a new service, I need to retrieve my backup key from storage for the purposes of enrolling. Depending on how/where the backup is stored (bank box, parent's house across the country, etc) that would make the system less workable in practice.
I use it to store my gpg keys among other use-cases. The key provides a permanence and isolation. I can't accidentally delete it without trying and the button needs to be pressed to access the key. I like these trait.
I think a huge benefit of 2fa, one of the main purposes of it, was for securing accounts with weak passwords. Back in the days before password managers etc. I think these days password managers actually deprecate the need for 2fa
Multiple layers are always better. If your computer or browser is compromised, then your password manager's secrets have been pwned, but with 2FA your accounts are still safe (assuming the 2FA is on a separate device, which it really should be)
There's also non-tech users to consider. It's pretty hard to convince users to use a password manager; plenty of people still re-use the same password across sites. It's impossible to prevent that. But it is possible to enforce 2FA for _your_ site.
Your first example is interesting, but it's much more limited than you describe. The attacker can't use your credentials to authenticate their own session, but they have complete control over the authenticated session on your laptop. I can't think of an account I have where that would be meaningfully less bad.
The attacker has access to all of your authenticated sessions on your compromised laptop. They don't have access to any un-authenticated accounts which have 2FA enabled.
Passwords are an antipattern. Password managers are just a crutch to make it less painful.
Password recovery is often done through the phone via SMS (health care/banking) when a 2FA hardware key would be safer. And since you're implementing 2FA, just remove the password, and ask the user to use the 2FA key.
I think my favorite example of using SMS in the least sane way possible is PayPal.
I have a hardware key AND an authenticator app active for the account, but they STILL won't let me send transactions without entering a code sent to my phone number. And actually, not even then, because even though I receive the code fine, they say they can't authenticate me and don't give me a chance to enter it. Yes, it's a VOIP number, but it's been the same VOIP number for the 10 years I've had the account. It's not like it's new.
I needed to recover my user account / password through Voya recently for a corporate 401k.
They needed to send me 3(!) SMS messages in the process. One to get the username (with a valid email address). One more to request to change the password. And one more to actually change the password.
Every now and then you hear about a leak at some company that was storing passwords in clear text. Thanks to password managers this only affects that one site, but it still makes me thankful for 2FA.
I don't understand the threat model there. Wouldn't nearly all hacks that lead to plain text passwords also allow the hacker to access all the login-protected data, making a more secure login process pointless?
I'm guessing this won't work for sites where a real device is mandated. I believe on Vanguard, they were enforcing only permitting real Yubikey devices with real Yubikey certificates.
Vanguard changed their policy when they switched from the u2f javascript api/shim to webauthn. I was able to register non-fido keys with vanguard a few months ago.
All I want is to be able to use Touch ID for services that only support Yubikey. At my workplace this means Duo - they have Touch ID support, but only in Chrome! In Safari or Firefox Touch ID is not an option which is very annoying.
I would be very interested in a virtual Yubikey backed by Touch ID and the Secure Enclave.
If it requires developer action to support, then no. I want Touch ID to mimic exactly a USB Yubikey so that it works even when developers have no interest in updating their software (I.e. Duo)
Anyone here do what I do, a simple encrypted Linux volume + "oathtool" powered script?
Yeah, I know, same device, blah blah. I'm still pretty comfortable with it and I just don't like having this stuff on my phone, which perpetually feels less safe.
Whoa. I'd never dived into the whole hardware key thing because I never felt like I needed it -- except one (AND ONLY ONE) of my 2FA deals requires a specific app (i.e. they won't give you your generating token, you have to use Duo Mobile or a device).
As I'm seeing it, "virtual-fido" will let me fake a hardware device and get me so that I only need the laptop for 2FA? Gotta look into this.
This is fantastic. Did you make this, cmdii? Why does it need to persist files locally? I thought that all that's necessary is the key. Is it for resident keys?
I'd like a virtual FIDO2 device where I have to type a password/passphrase when I launch it, and it derives a FIDO2 key from the passphrase. That way, I can have my 2FA device with me in my head, and still get all the anti-phishing benefits of WebAuthn.
Certainly, it's much easier for the passphrase to be stolen/keylogged, but it's a nice option to have.
Yup, I built this. The file storage is only for the FIDO2/WebAuthN device, which generates large private keys for each credential; the U2F device keys are small enough that they are actually encrypted/stored in the key identifier that is passed in by the client.
I’m currently working on trying to expand this out with new features, as most of the work here was actually emulating the USB device which involved a lot of different layers of protocols.
Very nice work! This is one step closer to a password manager that doesn't actually need to store any passwords, just one key.
I'm not very familiar with FIDO2, but I thought the private keys for each credential were derived from the single key in the device and the website's domain? Is that not the case? Or are you just generating separate credentials per site and keeping those?
If the latter, couldn't you derive all credentials from a single source of randomness and skip the storage?
Each credential has its own private key which is signed by the device's private key for certification. I am uncertain if the FIDO2 spec says how those private keys need to be generated; right now they are generated randomly but they could easily be generated from a single secret/key, much like you suggest.
Ah, right. Yeah, as far as I know, Yubikeys and other devices derive them from a single random value that each device comes with. This is due to the lack of storage space in the devices, as most of them aren't even writable at all.
If you want to switch to deriving keys this way, you could save the storage space and make the program almost stateless. You'd still need the initial random bits, and those could be stored somewhere (they can probably be just 256 bits or so) or come from the user in the form of a passphrase.
Why not use the Linux USB gadget stuff, instead of USB over IP? With the dummy_hcd Linux kernel module you can attach virtual gadgets locally. I guess you still need USB/IP for Windows though.
Anyone know if there is a way to do WebAuthN without loading JavaScript from the website? Perhaps a Web Extension that reimplements the login requests for every website that uses WebAuthN will be needed, since there isn't any standard protocol for WebAuthN login between the browser and website, just whatever the website implements in JavaScript.
Thanks, appreciate the package. I submitted a PR as I was also looking for a Go package similar to this, and wanted to make using this as a library a bit easier. I plan on using this to automate some website login/authentication flows, where physical tokens are (for obvious reasons) not really a possibility.
Personally, I prefer the "approval" process of YubiKey/U2F devices over having to enter a code, but I also dislike having to have a hardware device on me at all times. Also, with WebAuthN and passwordless login, YubiKeys are now able to be used to authenticate people, so I figure it would be nice to have a software solution for that.
Granted, this is still just a demo, so it's a long way off from something somebody would regularly use.
this might help w/ adoption. it would be _really nice_ to use FIDO, but I don't want to restrict my usability to people willing to carry a key around. as a compromise I think having a weaker key is better than having paths where pki is disabled
The entire point of something you have is that it's physical and can't be copied. This isn't something you have, it's something you know with multiple layers of obscurity on top of it.
Author here. The credentials are encrypted on-disk with a passphrase, so it wouldn't be trivial extract them, but yes it would be somewhat less secure than a hardware device. I would consider it similar in security to a local password manager. (Note: this software is in beta so I wouldn't yet use it for significant security operations)
Personally, part of the motivation for creating this was to find a middle ground between the most-secure hardware keys and the least-secure password options for authentication. I would argue that requiring users to have hardware is one of the main reasons we only see YubiKeys as a second factor, even though they benefits outside of being based in hardware (namely the lack of phishable passwords).
I hear that Apple is creating "passkeys" which are essentially what you have created; FIDO/WebAuthN that is implemented in software and are even syncable into the cloud.
If the computer is compromised you're screwed either way. Even though WebAuthN can't be easily MITM'd like TOTP codes, someone compromising your computer could just use the UI to lie to you.
I think the main reduction in security is just that the virtual 2FA device is "cloneable" vs a hardware FIDO2 token where IIRC you can't extract the internal secret. So you're getting TOTP levels of 2FA (which also uses a cloneable initialization secret) thru a FIDO2-ish UX which seems like a reasonable thing to want.
They could, but it's still limiting - the maximum number of challenges the attacker is able to satisfy is the number of times you touch the token before you realise that something's up.
Based on a certain recent high profile hack, getting just one 2FA auth this way could already be enough ;-)
I doubt most people would be suspicious if their system prompted them to touch their key, they touched it, the software kept waiting, so they touch it again and it works this time.
If someone uses my computer to lie to me about bank transaction, SMS 2FA still shows amount and type of transaction. That's kinda a problem with few of the 2FAs, there is no context attached to code
On iPhones and TouchID capable devices this has been available for quite some time now. I don't know how much work setting this stuff up is, but AFAIK FIDO2 is already available on-device.
Using an external device for FIDO2 authentication is something I can't add much about. The FIDO2 standard should allow for this and Apple and Google are working to make such a mechanism available if I recall, they made a whole PR thing out of their FIDO2 support a month or two ago. There are apps that can do this as well though I don't know any specific ones for the Apple side of things.
anyone know which protocols specifications were relevant to this project? more specifically, which ones does it implement? Is this stack fully specified?
