Biometrics are simply the equivalent of tapping a FIDO2 button. They don’t increase security as much as they are a signal to authorize that prevents less dedicated users from opening the device. The device, not the biometrics, provides the security guarantee to replace a password.
You can opt to replace any biometrics with a device-specific password that is more secure than other passwords because it never leaves the device or even an additional two-factor key, at the option of the device maker.
For example, you can use a separate FIDO2 key within Windows Hello for enterprise use cases against Azure AD instead of using biometrics to sign in to your computer.
Folks can choose what level of security they are comfortable with. For me, personally, and everyone I know, passwords are much easier to steal and reuse because they leak regularly, can be tested multiple times without consequence, and so on.
To be clear, I’m saying password managers are awesome but device-based security is more awesome. Add a local password to your device based security is more awesome still, but then so is having a friend approve your request or other additional layers of security. Biometrics are the new PIN code “minimum” not the best we can do but better than sharing one string of text with the rest of the internet and assuming it will never leak.
Note that the risk model is roughly identical if a device is lost. Just as with a compromised password, you would have to visit websites using the device directly and revoke its access. This is made simpler if you combine FIDO2 with OAuth2 because then you only need to de-enrol the device from Microsoft or Apple. OAuth2 provides an additional layer of protection because it can tell you when your device is used, and can add additional security factors such as notifying you when a login occurs that not every site might build. OAuth2 does this by replacing passwords with timed tokens depending on how it’s configured, so at minimum new tokens are logged.
The same applies to the use of short-lived credentials in AWS or other cloud providers vs using permanent secret tokens. When using permanent secret tokens, like passwords, these are often very hard to rotate without consequences because you do so very rarely. They are also subject to reuse on different machines. By comparison, a short-lived token can use machine identity on a cloud server to add an additional layer of protection, and depending on the authorization system could validate a local device, use of a second FIDO2 or biometric device, validate the server requesting delegate permissions on your behalf, and validate the duration and scope of data being accessed, all at the same time.
In highly sensitive scenarios, one could even use asymmetric encryption stored on devices to ensure that any intermediate or delegate servers cannot decrypt API responses, only the recipient of the data. Of course, you need a model to trust your client app, but App Stores notarization and containerization go a long way to making it easier to wipe and redeploy secure machines frequently, such as with every system update, optionally leaving user data alone.
There's a difference. If your FIDO2 key has biometrics (such as touch ID) then it's still a FIDO2 key. It means if it gets compromised (lost or stolen, for example) then you need both the device and the biometrics to gain access.
If your fingerprints are lifted/leaked from a glass, for example, then published, your attackers also still need physical access to the device you use biometric security against.
If that's public, such as your house front door, I agree, you've a problem. If that's your cellphone, then you have to ensure you don't leave your phone unsupervised.
The same is frankly true of other exploits that can be done in-person, such as USB attacks or PIN code screen bypass, and so on. Once you have physical access to a device, you can authenticate via many means, not just biometrics.
You can opt to replace any biometrics with a device-specific password that is more secure than other passwords because it never leaves the device or even an additional two-factor key, at the option of the device maker.
For example, you can use a separate FIDO2 key within Windows Hello for enterprise use cases against Azure AD instead of using biometrics to sign in to your computer.
Folks can choose what level of security they are comfortable with. For me, personally, and everyone I know, passwords are much easier to steal and reuse because they leak regularly, can be tested multiple times without consequence, and so on.
To be clear, I’m saying password managers are awesome but device-based security is more awesome. Add a local password to your device based security is more awesome still, but then so is having a friend approve your request or other additional layers of security. Biometrics are the new PIN code “minimum” not the best we can do but better than sharing one string of text with the rest of the internet and assuming it will never leak.
Note that the risk model is roughly identical if a device is lost. Just as with a compromised password, you would have to visit websites using the device directly and revoke its access. This is made simpler if you combine FIDO2 with OAuth2 because then you only need to de-enrol the device from Microsoft or Apple. OAuth2 provides an additional layer of protection because it can tell you when your device is used, and can add additional security factors such as notifying you when a login occurs that not every site might build. OAuth2 does this by replacing passwords with timed tokens depending on how it’s configured, so at minimum new tokens are logged.
The same applies to the use of short-lived credentials in AWS or other cloud providers vs using permanent secret tokens. When using permanent secret tokens, like passwords, these are often very hard to rotate without consequences because you do so very rarely. They are also subject to reuse on different machines. By comparison, a short-lived token can use machine identity on a cloud server to add an additional layer of protection, and depending on the authorization system could validate a local device, use of a second FIDO2 or biometric device, validate the server requesting delegate permissions on your behalf, and validate the duration and scope of data being accessed, all at the same time.
In highly sensitive scenarios, one could even use asymmetric encryption stored on devices to ensure that any intermediate or delegate servers cannot decrypt API responses, only the recipient of the data. Of course, you need a model to trust your client app, but App Stores notarization and containerization go a long way to making it easier to wipe and redeploy secure machines frequently, such as with every system update, optionally leaving user data alone.