Dumb question: why are biometrics being used to replace the password, shouldn't the biometric replace the username?
Prior security seemed to focus entirely on attackers, and their agency, and what they could potentially do. But we also need to pay attention to what users can do in order to build a secure system. Requiring users to read domain name strings, potentially in Unicode, every time, and make sure they are correct, to prevent phishing, is a really bad design. Instead, have the website authenticate themselves to the user, automatically, and have the machine do the string comparisons.
Similarly, the distinction between user and password for a biometric doesn't make much sense in this case. It's neither. The user is identified by a different mechanism, the biometric is merely a way for the device to see that the user is there.
There are always lots of attack modes for biometrics, but they are convenient and good enough to capture nearly all common and practica attack modes. And a huge problem of the 90s and 2000s security thinking was focusing on the wrong attack modes for the internet age.
Don’t think that’s quite true. It’s continuation of the old “something you know”, “something you have” and “something you are” authentication factors, and the idea that at least two factors should be used to authenticate.
The username/password approach is only a single factor, “something you know”.
Common 2FA solutions use “something you know” (you’re password) and “something you have” (a device proven via OTP or SMS).
FIDO with biometrics trades all that for 2FA driven by “something you are” (biometrics) and “something you have” (you’re devices Secure Enclave).
You don’t send you biometrics to the service your authenticating with. Rather you’re using your biometrics to prove “something you are” to your device, which your device then mixes with a private key which proves you’re in possession of a known device. All of that is then used to authenticate with your service.
In order to enable a cloud synced private key, you need the syncing process to require 2FA to enable new devices. The 2FA process can be clunky and slow, because you only need to do once per device enrolment. Indeed it’s need to be clunkier, because you don’t have a biometric factor available for use, as the enrolment process is normally used to onboard both a device and a device specific biometric factor.
After that you’re device becomes a know authenticated device, which can be used as “something you have” factor for authentication.
All of this isn’t a change from long standing authentication strategy. It’s just a refinement of process to make the underlying authentication strategy user friendly.
Pardon my pedantry, but you should only use the apostrophe (') to show you are joining two words.
In this case, the words are "you" and "are", merging into "you're". "you are password" is what I read.
> "but you should only use the apostrophe (') to show you are joining two words. In this case, the words are "you" and "are", merging into "you're"."
Is obvious, unnecessary and condescending.
An argument for keeping the username separate is it is often used for identification. That is, you identify on this site as alberth. Not as any biometric scan. Even if you change which finger you want to use to authenticate, you'd still be alberth to everyone else here.
I think there are arguments on favor of letting you change a display name. Probably still would keep a name that is static. (What Twitter does?)
It sounds like it's still a one factor authentication system, but different.
The standard allows for service to demand that the authentication device performs an additional factor authentication. Which is usually either a PIN or biometrics, and your device attests to doing this during authentication.
So then you have two complete factors “something you have” (your phone) and “something you are” (biometrics) or “something you know” (unlock PIN for device).
If you were sending an actual copy of your biometric data to the remote authentication service, then maybe you could make that argument.
But that never happens, no FIDO biometric device sends a biometric fingerprint that could be reproduced by a different device. The device authenticates you with biometrics, then uses that data to unlock a private key, which is then used to answer a challenge-response request from the authenticating service.
If you don’t the device, then it’s pretty much impossible for you to correctly answer that challenge-response, despite being in possession of the biometric features that device would use to authenticate you.
So you can’t use your biometrics as a username. Because the device measuring the biometric data pushes that data through a mono-directional, randomly generated (at device manufacture), hash function, that exists within that device only. Take your biometrics else where (I.e same device type/model but different physical object), and you’ll get a different output even with identical inputs. Which would be a pretty useless username.
> I'm not sure something you are counts as a security factor.
You should take that up with NIST then: https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/m...
In the same way that the security of something you know is a scale based on “how difficult is your password to guess” or “how hard is it to crack the hash” the security of something you are is a scale based on “how difficult is it for someone to create a fake that tricks this specific machine into thinking it’s reading metrics from a live human.”
The security lives in the system reading the metrics not your body which is why you don’t have to rotate your face every 90 days.
A cheap fingerprint reader is the 4 digit pin of something you are. Retina scans that take temperature, look for blood flow and eye movement are the correct horse battery staple.
- so what happens if you don't have your phone at time of login?
- if I enroll on iPhone, is my identity forever tied to Apple or can it be migrated to Android if I ever wanted to change platforms?
- Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc that use FIDO login?
You can’t login. Same as it is with any 2FA system where you don’t have access to the second factor.
> - if I enroll on iPhone, is my identity forever tied to Apple or can it be migrated to Android if I ever wanted to change platforms?
At a minimum services should support multiple authentication devices/tokens. So you can enrol both an iOS device and Android device, or any other FIDO device E.g. YubiKey.
This is already the standard approach for FIDO tokens, and basically a requirement for existing services, because we don’t currently have FIDO token syncing.
I would hope that these syncing services will also allow you to export your private key. But that’s a slightly scary prospect because it would allow the holder of that key to authenticate as you anywhere.
> - Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc that use FIDO login?
Services will still need a credential recovery process. People lose phone etc everyday. I imagine your bank will happy reset your credentials if you turned up in-person holding government identification.
A good FIDO implementation will give you the ability to enroll multiple authenticators. In fact, if you can't, you're basically going against the WebAuthn spec.
"Relying Parties SHOULD allow and encourage users to register multiple credentials to the same account. Relying Parties SHOULD make use of the excludeCredentials and user.id options to ensure that these different credentials are bound to different authenticators."
Basically, you should enroll your iPhone and a backup key. And if you get an Android device, you log in with the Android device using a backup key, and enroll the Android device and remove the iPhone. Alternatively, you remove the iPhone authentication using the iPhone, and enroll the Android device using an alternative authentication method (like traditional username/password).
If you don't accept their 10,000 word ever-changing terms of use, and if don't let them check for the marks on your forehead or right hand, then yes, you won't be able to buy or sell.
You technically should be able to migrate from one provider to another, it remains to be seen how easy Apple and Google will make the process.
That last one is a great question that I don't know the answer to.
On a UX level, the transfer to another syncing security key "provider" is going to be interesting, if they even do that at all - I kind of doubt they'll have a "transfer your iCloud passkeys to your Chrome password manager" and they'll instead say "go to each service and enroll a new security key via your new syncing key manager". On a technical level, I wholly imagine there'll be a tool that pulls iCloud Passkeys[0] via the MacOS Keychain application and then inserts them into your new key manager.
0: https://developer.apple.com/documentation/authenticationserv...
Depends on if they allow you to turn off password+2FA login entirely, which I only see being possible with something like Advanced Protection Program[0] which can already be used to enforce "Only allow authentication with my password+security keys; there is no way for Google Support to remove 2fa; if I lose the keys, the account's lost".
> - if I enroll on iPhone, is my identity forever tied to Apple or can it be migrated to Android if I ever wanted to change platforms?
I imagine they'll say "login to each website" (which you can do via iOS if you use qr android login[1]) then "re-enroll with your new provider", but I hope there will be an actual export/import or migration experience.
> - Can Apple/Google/Microsoft ever block/ban my account, preventing me from logging into my bank, etc that use FIDO login?
Assuming they don't change how Chrome and iCloud keychain currently works, everything synced should stay on your already signed-in devices, so hopefully you can continue to use your devices as authenticators until you can log into each service and register a regular, hardware key for sign-in.
0: https://landing.google.com/advancedprotection/
1: https://www.chromestory.com/2021/12/qr-code-2fa/#:~:text=Her... I personally tried this with my iPhone, and my phone prompted me to use an iCloud Passkey. I was able to confirm that, by enrolling my iPhone as a security key on GitHub, then this 'BLE Webauthn' feature allowed me to sign in to GitHub on my desktop Chrome browser via my phone. Only downside to this is that the desktop must have a bluetooth card, but hopefully motherboards will continue to come integrated with wifi+bluetooth.
Its not like InfoSec cares if the business functions, that's not their job.
You don't need an Apple/Google/Microsoft account to use WebAuthn on another website, it's based on the biometrics on your local device. Syncing that credential across your devices with the same account is just an optional extra feature.
Biometrics are a convenient replacement for a screen lock pattern/PIN, but not a necessary one, of course.
https://www.wired.com/story/fido-alliance-ios-android-passwo... is a good explainer.
If you don't then the biometric marker can just replace both password and username. The reason why the username exists for the password is because it's problematic to guarantee uniqueness of passwords across your users. One is unique and public and the other is not and private.
You associate biometric credentials to a username for that.
Also, the biometric does not actually replace a service password in this instance, it just helps authenticate you locally to a device. The key on the device is what is actually replacing your password.
Depending on the device or settings you choose, you don’t need to use biometrics at all if you don’t want to.
i.e. lockpicking howtos and existence of glasscutters don't dissuade from having a locked front door.
Username is simply an ID. Password is how we truly verify who the user is.
Bio-metrics are just convenient because they are unique and hard\impossible to replicate.
But if your biometric is able to be faked, you can't change it like you can change a typical text based password. There's no "reset your password" equivalent for biometrics.
The signal from the sensor is used as a "seed" to generate key using robust cryptography
Different sensors will output different "data" based on the sensor type.
Unless you have a drivers license in California where they require inked versions of your biometrics.
Isn't it a fair argument that secret keys should be mutable by the user? In the future, some unforeseen event COULD occur which compromises or otherwise renders the particular biometric unusable. Now what?
I think what you want is secret keys completely detached from the user. we have that as well with hardware tokens.
As I explained you can't get the fingerprint from the device\key, it is simply not there.
This isn't the problem of the implementation\technology if someone stole your fingerprint. it didn't lead to your biometrics compromised
What's easier to do? stealing someone's fingerprint or cracking\guessing their password.
Definitely the latter.
> Definitely the latter.
You sure about that? A properly generated (i.e. random) password won't be cracked or guessed in any reasonable amount of time, whereas a model of your fingerprint(s) can be lifted from any object you've touched and used to create a silicone mold capable of fooling many fingerprint readers. And you only have 10 of them at best; once all your fingerprints are known to potential attackers that's it; you can't use fingerprint authentication any more for the rest of your life.
Do you even listen to what you're describing here? trailing someone, trying to extract fingerprints? this isn't a Jame Bond movie.
Cyber attacks are common because they are completely digital\anonymous by nature.
Secondly, humans can't remember\generate truly secure passwords, unique for every account they own. they usually rely on a tool like a password manager.
PM are definitely better than weak passwords but are actually weaker than biometrics. they are a central point of failure and have been attacked in the past.
For the average Joe, biometrics are more secure since he is not using such tool anyways.
It doesn't take James Bond to lift some fingerprints off a surface. Anyone with physical proximity and a little practice can manage that much. People have managed to fool fingerprint readers with Gummi Bears before, much less specially-designed equipment. It's a practical attack, unlike attempting to brute-force a truly random 10-character password from a 78-character alphabet (uppercase, lowercase, digits, and half of the 32 symbols on a PC-104 keyboard).
> Secondly, humans can't remember\generate truly secure passwords, unique for every account they own. they usually rely on a tool like a password manager.
Which is perfectly fine. You aren't going to break their password manager either. The weak point is the users who aren't using password managers, because they try to get by with less-than-random passwords which are susceptible to cracking. Or biometrics, which aren't secret at all.
Password based biometrics is the last place I would look at for biometric compromise.
We leave biometric traces everywhere, all the time. do you cover your face and wear gloves in public? hmmmm...
right, who would do that... i mean for what purpose...
FIDO simply wants to make authentication stronger, you can use hardware keys that have a key burnt into them which is unique and much harder to brute-force than passwords.
Again according to how biometrics are described in whitepapers\industry, we extract features from the fingerprint\face sometimes very little compared to the actual biometric and use it to derive a key. that key cannot be reversed to get the original features and different algorithms use different features.
"As a result, the early common belief among the biometrics community of templates irreversibility has been proven wrong. It is now an accepted fact that it is possible to reconstruct from an unprotected template a synthetic sample that matches the bona fide one."
-- Reversing the irreversible: A survey on inverse biometrics
https://www.sciencedirect.com/science/article/pii/S016740481...
> there are studies showing that the hash could be reversible, that is, it could be possible to obtain the original biometric pattern, especially if the secret of the key used to generate the hash is violated
So yes, there are secret keys involved (which the user has no control over), and no, I've never read through the code of a biometric implementation, but ultimately the space of possible values that someone's face or finger could reliably display is much smaller than even MD5, so it can be brute-forced.
If you have some non-random internet page to justify yourself, and show how much entropy is contained in a biometric hash, and how resistant to cracking that hash is, and how well secured those secret keys are, then I'd be happy to learn more.
[0] https://edps.europa.eu/sites/edp/files/publication/joint_pap...
also you
> We leave biometric traces everywhere, all the time. do you cover your face and wear gloves in public? hmmmm...
a photo\mask isn't perfect and actually in some instances they fail to work vs sensors because of that.
It is more of a question of how robust is the authentication method.(can a photo\mask fool it? which can happen sometime but usually require pretty high quality sample)