Yeah its probably better than 80% of people having "password123", but it seems strictly worse than a password + password manager? Or at least just having proper 2FA.
I agree - not secure.
And just a daily reminder that biometrics are usernames, they are not passwords. You can change a password, a lock, a key, you cannot change biometrics, and thus they should not be used for guarding sensitive info.
The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate surveillance.
I think you should stop giving out this daily reminder. This meme has outlived its usefulness.
Using face id to unlock a local key store to enable my device to sign a signed challenge from a site I want to log into with the private key stored on my device is not a 'username' in any meaningful sense.
The problem is, the metaphor about passwords and usernames is not a good, structure-preserving simplification of the actual problem of authentication.
The biometric data and/or pin code are not being used to prove that you are you to Gmail, it's being used to unlock the set of private keys you have on your device. This doesn't fit into the metaphor at all.
If my non-technical parents said they were migrating all their accounts to passkeys, I would be very pleased. I wouldn't be worried about their inability to change their biometrics and that causing a problem following some sort of breach in the future. I am highly worried about their extreme susceptibility to phishing, especially in their inability to distinguish phishing sites from real sites, or real account maintence contacts via email and SMS from phishing contacts, their reuse of very simple passwords that are probably circulating in combolists already, and their general inability to retain username/password pairs. I have a lot of sympathy for them when I try to talk them through something like logging in to an Apple device with their apple id, when their appleid username is their email, which ends with @gmail.com. "But...why would i log in to apple with my gmail?" nevermind how confused they are about 'log in with google', 'log in with facebook', etc.
Moving to a model where their devices store webauthn credentials and guard them with a pin or faceid-style biometric shortcut is a _massive_ improvement in practical resistance to account takeover for my parents, and I don't think continuing to say 'biometrics are usernames in authn' is accurate or helpful.
My 76 yr old dad can't do it. His phone is some shitty android trash that when he's setting up his biometrics, he shakes a bit, and it never stores the finger data correctly. I have to hold his finger and his phone at the same time to even scan it. Then, unlocking is also super unreliable because of the shaking. He refuses to get a better phone cause this one "works well enough."
It's no surprise that the tech industry, which largely employs urban, educated 20-somethings and 30-somethings, tends to produce products aimed at urban, educated 20-somethings and 30-somethings.
Stick your finger inside of a dynamically sizing aperture, or clip a finger reader onto your finger? If both the finger and the reader shake the same there shouldn't be a problem.
That doesn't solve the general touch issue, but it solves this particular case.
But sure, I agree (https://news.ycombinator.com/item?id=35790638 ). I'm just trying to come up with some workable solution. Not trying to make the best of all possible worlds.
Essentially every biometric has a population they won't function well with.
Security is HARD. There's no getting around that. Your data is valuable and protecting it is not an easy task. At some level, security and convenience is a zero-sum game.
As for old people, my dad writes down his passwords on a text file in his laptop and has a printed backup in the house.
And, yes, he does have to bug me sometimes to re-login or change a password, but we've never had a security problem, which is way more than can be said for a lot of people who tried the INHERENTLY unsafe "3rd party manager" thing.
No it's not.
The security triad is "something you are", "something you know", and "something you have". Fingerprints are something you are. Usernames are something you claim to be.
The username is the "claim" you are this person. The password is the "proof" you are.
If I'm fingerprinted by any federal agency today (and my fingerprints have been on file with the government since the 90's for a security clearance), then my fingerprints can serve as absolute proof of my identity. This is helpful to me should my identity ever be stolen and I need to show absolute proof of who I am.
But given the relatively high level of laziness, capriciousness, and general failure all around that is "IT security by means of companies who are rarely held accountable," it's good to point out that this is what makes biometrics worse than usernames and should probably mostly be avoided, or at least optional.
Sure fingerprints, face scans, and iris scans can be stolen as well. But certain things are really hard to fake, including potentially, scans of faces and an iris scan at the same time -- unless you can somehow graft a new iris and grow a new face.
Put it like this: a dead victim is found naked along the side of the road. Which leg(s) of the security triad can the police use to prove the identity of the victim?
Google, who I don't pay and doesn't owe me much, not so much.
Please provide evidence that biometric data has ever been extracted from a major platform (IE Apple/enclave). Absence of evidence != evidence of absence, I know, but you’re selling it as the only use case so surely you have proof.
Why extract it from a platform when it can be extracted easily from the person? Imagine your password was written on every surface you touched (fingerprint) or is prominently displayed on your social media accounts (face).
The biometric doesn't exist until you enter your PIN on restart, which is what unlocks the filesystem (including the biometric profile).
You'll also see that you can change your biometric with just your PIN, but you cannot use your biometric to change your PIN.
If the algorithm is not known, it’s only a matter of time it’d be leaked or reverse engineered. And then suddenly there’d be a massive, difficult to fix security breach. Just like the breaches that we have now, with voice based authentication.
Can someone explain, how this can be mitigated?
But if this is used only to unlock the trust zone/secrets, I guess that works. It seem to be extremely dependent on the device not getting locked up accidentally, lost or damaged. If a damage would lock you out from all of the accounts, this seems rather drastic.
Your face geometry is used to allow access to a secure processor (trustzone/Secure Enclave/etc) which then signs the web token.
Which is why the phone is the “something you have” piece of the puzzle here.
Everything you’ve described can be done whether or not I use biometric to sign into a device, or even own a device?
My apple touchID never works because I rock climb and I guess that abrades the skin too much
Relying on fingerprints to gain access to things on a regular basis never seemed like a great idea to me.
Bodies are not invulnerable to damage. You can absolutely change your "biometrics", you just probably wouldn't _want_ to.
While I see where you're coming from, they really aren't just usernames. It's not like I can log into your e-mail account by typing VoodooJuJu and pressing Enter.
Most sites already don't store the password. If you have a sufficiently strong password (i.e. very long, randomly generated, stored in a password manager), it is likely not computationally easier to recover the password from a hash than it is from a public-key. The only improvement here is that you don't have to trust that the site is following best-practices for storing passwords, as you never send them the password.
[edit]
It also prevents phishing attacks for those using some form of entering a password other than autofill from the password-manager.
The three factors of authentication are:
1. Something you have
2. Something you know
3. Something you are
Passkeys are typically 1+2 or 1+3 — you'd need to have physical access to the device either way.
Thus, even short PINs can provide strong security since the attacker gets, e.g., at most 10 tries to guess it out of 100k possibilities for a 6-digit PIN.
Has anyone seen any docs that might help characterize how much entropy the keys have for e2e encryption (Android/iOS)?
I must be missing something, because I can't see how Google would call something e2e encrypted if the keys only have like 30-35 bits of "effective" entropy after a KDF. But that seems like it's the case??
[1] "From the user's point of view, this means that when using
a passkey for the first time on the new device, they will
be asked for an existing device's screen lock in order to
restore the end-to-end encryption keys"
[2] https://www.omnicalculator.com/other/password-entropy?c=SGD&...
The PIN and key derivation wraps the actual encryption key that's stored locally in the device or secure enclave, not the actual secrets that are stored in the provider's cloud. The actual wrapping keys are random 256 bit AES-GCM keys. This approach works because the secure enclave provides measures against bruteforcing and tampering.
There is some controversy that I can't find an explanation for in any whitepaper, specifically here: https://support.apple.com/en-us/HT202303 where it reads "(...) this data remains secure even in the case of a data breach in the cloud. If you lose access to your account, only you can recover this data, using your device passcode or password, recovery contact, or recovery key." because that implies off-device use of the PIN, so those measures are lost. There's no further explanation that I could find about that. Some previous discussion about that particular point here: https://news.ycombinator.com/item?id=33897793&p=2#33900540
> This approach works because the secure enclave provides measures against bruteforcing and tampering.
That's interesting!
> because that implies off-device use of the PIN, so those measures are lost
This link from your previous thread is interesting: https://support.apple.com/en-sg/guide/security/sec3e341e75d/...
Uses SRP to let the device prove to iCloud HSMs that the user entered the correct pin, without ever sending it over the wire. The HSMs have similar protections for brute forcing, etc.
From the docs I have a fairly high confidence entropy is 256 bits for iCloud Keychain. I have much less confidence on Android, but I'm still researching... :)
This thread really smells like https://xkcd.com/538/. Three things you have to remember, that are far more important than any of the concerns you have:
1) The effective entropy of the current system (passwords) is "shrugs shoulders fuck it not our problem". Services can enforce password entropy requirements. They cannot effectually require users to use a unique password. They also cannot forbid users from writing the password they use in a .txt file on their desktop or post-it note or throwing it in Apple Notes (EVERYONE does this outside of our bubble. Apple Notes and Excel are the #1 and #2 password managers on the planet). A six digit pin + hardware TPM key derivation is, at best, the same thing that was guarding how most people store their passwords anyway, and in many cases far better than the current state (if a user's device has no E2EE, or if they're syncing their passwords.xlsx file with Dropbox, etc).
2) Passkeys do not and are not designed to protect against nation-state level attackers. Passwords weren't either. They also don't protect well against the "grab a hammer and beat it out of him" threat vector; you're going to give up your password, and tomorrow they'll probably have your iPhone and your passkeys will be disclosed as well. Passkeys are designed to protect against unsophisticated (and even moderately sophisticated) attackers; phishing, data breaches, etc.
3) If you want higher tiers of entropy guarding your passkeys, you can do that. 1Password, as an example, already has this [1]. They store passkeys, and encrypt those passkeys with their two-level account & master password keys. Done! If you don't like 1Password, you can roll your own, and I'm sure OSS password managers like gopass/keepass/etc will eventually add this. Passkeys/WebAuthn don't prescribe to anyone how you store the private keys; Apple will do their thing, Google will do their thing, you don't have to use them, many people will, and they'll be better off (see point 1).
Thank you. 100% agree.
> Passkeys do not and are not designed to protect against nation-state level attackers
I've been mulling over some use-cases where this is important, hence the deep consideration over entropy. 100% not a huge deal for the passkeys case for many 9's of people.
I don’t know what “proper 2FA” means but the gold standard today is U2F, and it has failed to be mass adopted due to requirement to purchase and maintain another device.
You enter a pin, the web server sees a public key that only your side has the private key to.
Your password manager is likely the exact same thing. The underlying implementation of this is typically a system or third party password manager which added a public key-based credential type for sites. For an Android phone, this is Google Password Manager by default. For iOS, it is iCloud Keychain. Third parties like Dashlane and 1Password have indicated support for passkeys.
I would have thought your interpretation would be that this was strictly better. Even if the credential database leaks for a site, the attacker can't do anything with it - all they have is a public key, specific to that one site.
> Or at least just having proper 2FA.
If I use my android phone to log into a website, I have done 2FA. I have physical possession of my phone, and have used a gesture, PIN or biometric to confirm who I am.
The difference is in the password case, the website has no idea that I did that - all they saw is the password. With a passkey, it is possible that a site would recognize that I did a stronger, multi-factor authentication.
This may have varying strengths as a physical factor - say, provisioned database of credentials onto a device using MFA vs a FIPS-certified security key fob, but I would still argue it is "proper" 2FA.
Slightly off-topic: If a website will not let me register and complains that my password is too long, they're still storing that in the underlying database as a properly-salted (modern algo) hash, right?
2FA via SMS is still vulnerable. 2FA with an app like Google Authenticator or VIPAccess is more secure because it is tied to a device.
Tied to a phone (as opposed to some security-specific device like a Yubikey) is a terrible idea.
It ties your authentication to something that is often lost or damages, but more importantly, something that is controlled by a third party (apple or google) and requires an expensive monthly subscription to yet another third party (your cellphone company).
TOTP is not tied to a device which is why it's a beautiful solution. You can store it where you wish under the controls you wish and back it up as you wish. You are fully in control, dependent on nobody.