It seems like every single HN thread on biometrics somebody comes in to proclaim for the nth time that "finger prints aren't passwords!!" or something of that nature, as if "something you know/something you have/something you are" haven't long been known and considered as basic building blocks of authentication with various tradeoffs vs different threat scenarios. Your kind of oversimplification is not helpful given that it can actively harm real world security, which requires amongst other things actually working with how actual humans really are and making the right economic tradeoffs.
You might still need a PIN to install an OS update, but that won’t keep someone from going through all of your photos and emails.
So you'd say that "there is an actual master password and the biometric authentication is being combined with a physical token as a shortcut/proxy" then? Because that's what it is.
>but that won’t keep someone from going through all of your photos and emails.
Neither will a PIN in a targeted physical attack. The long, good master password can defend against offline attacks (including most particularly backup data stores off of any specific device), serve as a line of defense against lower level modifications, etc. You keep "someone" from going through device data through physical defense of the device, difficulty of time-to-attack vs methods like remote wipes or physical limits, network reqs, perhaps coercion code/auto sensor limits down the road, and on and on. All within the framework of expected cost/benefit, like all security.
It's like keeping a safe unlocked while keeping the safes bios protected. It's the content that matters not the OS.
I'd say that the fingerprint is the single factor to unlock your phone and access all of your data. Sp I'm not sure I understand your point about a physical token. That the phone is a physical token that you need in order to unlock the phone?
I guess that's true, but it's a weird way of describing it versus just calling the fingerprint a single factor used to unlock the physical device.
That feels like saying "My house has two factor authentication, one factor is they key and the other is the house." The house isn't a second factor, it's the thing you're getting access to.
No, it's an important (and interesting I think) difference. Compare to many of the systems you deal with otherwise: with most of them the specific physical thing you're using to access the data isn't that (or at all) relevant. With your HN account for example, if the password were known then it doesn't need to be access from one of your devices. Nothing of yours needs to be physically possessed. You could say storage on one of your computer systems would require more physical access, and that might sort of be true (there are gradients in all these things), but from a pure technical perspective general practice has been, even with full disk encryption, that the password is still the root. For software FDE the password is generally going to go through a key stretching algorithm to turn it into something cryptographically usable and add some resistance to brute force of so-so keys as well as time/memory tradeoff attacks (rainbow tables), but it's a deterministic process. If you know the password, the key can be generated, including if the drive was pulled and put into another system or imaged onto some other piece of hardware entirely. Getting access to the data may present challenges depending on where is (local could be harder then an attached drive which might be harder then a LAN volume, or the reverse). But once that data is acquired, knowledge of the password is sufficient.
But with a good smartphone (and starting to be more in computers via HSMs or built-in like Apple's T-series of chips) it'll instead be that the authentication factors go to a blackbox dedicated security chip, and that then handles keys which are entangled with hard burned-in data specific to that device. You cannot pull the storage or image it then unlock it, knowing the user's password is insufficient. For any data using that phone's hardware security as its root, you must go through that specific, physical chip regardless of any knowledge of biometrics or passwords. It is an integral part of the data security in a way that is not yet typical for traditional systems (let alone online). As far as I know all of those systems still have a password as one way to authenticate to them, with biometrics being another, and in principle they could make use of further automatic sensors too as well as do interesting things like require different authentication factors for different operations, or enable powerful anti-coercion features.
Of course, it also means if that chip ever has any trouble or gets lost better hope to have backups because otherwise you're hosed, no recovery is possible even if the physical storage is completely fine and all the encrypted data is right there.
So "what you're getting access to" is the data and operational capability of the phone, but "how you do so" is going through a "separate physical token authenticated by another a 2nd/3rd factor" (the hardware security chip), no different then if you had a USB HSM you plugged into your PC and made it a blackbox requirement for data decryption or certain operations like signing. Just because the connection between the separate token and what you're accessing happens to be direct solder and traces on a motherboard vs USB or PCIe or whatever doesn't mean it's not a separate factor here. And as it's the physical token intermediating even total compromise of the system to be accessed doesn't by itself mean biometrics or passwords leak either.
For the security of my Gmail account you need 1) password, 2) TOTP code, 3) an internet connection to Google
For the security of a physical place like my house, you need 1) key, and 2) physically be at my house. The being at my house part is more analogous to having an internet connection than another authentication factor.
The phone as a material object follows a threat model like my house. If someone has a copy of my fingerprint and is physically at my phone that's like having a copy of my house key and being at my house.
It's true that someone in China can't remotely break into my phone with the fingerprint, just like someone in China can't take a copy of my house key and steal my television.
So yes, there's security value in needing physical proximity, but I think it's a stretch to describe it a second authentication factor.
How the secure enclave and encryption works is immaterial to the fact that if I leave my phone sitting on my desk, you only need one thing to get to my data, and it's a fingerprint that for all I know someone pulled off of a Starbucks cup 10 years ago after I tossed it into a rest stop trash can, and my only option to avoid that is "disable the fingerprint scanner" because it's a single authentication factor that I physically cannot change, unlike a leaked password.
Anyway, I think we agree on how it works, we're just arguing over the semantics of how to describe it.
Citation needed? A fingerprint can absolutely be used to generate a hash that functions as a pointer to primary keys.
Systems that try to do this in software are always trivially circumvented because you can just change the software to allow ‘not enough matches’ instead of ‘enough matches’. The key is necessarily in the device and software can’t protect it.
Because all of those apply to user IDs.
TLDR yes, biometrics are the closest thing to a user ID
> Are you seriously arguing a fingerprint is an aesthetic symbolic pointer in the way a name is? Absolutely. A given name is non-unique, and not chosen by you. Yet everyone refers you by it, if only by convention.
> That you are going to just refer to other people (whether IRL or online) by "fingerprint"? No but computers might as well do, much as you identify someone by their face. You might refer to someone by their public key fingerprint too (also similarly non-collision resistant)
> That people choose their fingerprints based on what they think will be a good one? People rarely choose their names, nicknames, or usernames. Why is choice an issue here?
> That there can just be a simple process to arbitrarily change their fingerprint if they later decide they'd prefer another one? People find it difficult to arbitrarily change their face, most are reluctant to change their given names - and indeed there's significant pressure from 'the system' to make it difficult for you, and also what about the many who find it annoying when their preferred username is unavailable, etc. I can't see what your point is here?
> Because all of those apply to user IDs. A user id, isn't a primary key in the real world - only when it comes to a particular computer system.
Finally your fingerprints do change over time, though not necessarily in a manner which will confuse current matching techniques
My point is a user name is something everyone knows i.e. not a secret.
Biometrics are not a secret as they are, in the case of fingerprints - easily picked from your Starbucks coffee cup, the door you just opened etc.
Your face is permanently on display.
Etc.
Your assertion that biometrics are not user-name equivalent is embarrassingly ignorant and you've already shown your inability to read or show much comprehension.
I shall therefore assume that you're unused to rational discussion and leave it there.
It's so odd to me that we consider fingerprints "something you are". Fingerprints surely are "something I have" in that I can lose them by disfigurement or maiming. "Something I am" is more like my DNA which can't be taken from me to the point of loss, unlike someone cutting off my fingers which would deny me access to whatever system it's used for.
so if you're merely saying (as i think you are) that biometrics make poor usernames, much as they make poor passwords, your argument is quite trivial/tangential to this thread and really doesn't address the point op is making and doesn't contribute to the thread in any meaningful way (unless you wanted to expound specifically on why its so important for usernames to be, mutable?)
and if, instead, you're saying, as you implied to me, that biometrics make better passwords than usernames, i'll reiterate: that's wrong.
Names/User IDs are not equivalent to biometrics. Nor passwords. Nor tokens. They are symbols that exist to enhance human UX. That's it.
>remember the context of the comment you criticized is that there are vulnerabilities in biometric security
Yes, just like in every single form of authentication. Which is utterly irrelevant.
>so if you're merely saying (as i think you are) that biometrics make poor usernames, much as they make poor passwords
>that biometrics make better passwords than usernames, i'll reiterate: that's wrong.
These are utterly non-sensical statements. Biometrics are not user names (a public symbol) nor are they passwords ("something you know"), "poor" has nothing to do with it, they are one of the other two classes of unique authentication factors. They have their own strengths and weaknesses, and yield different practical results when combined with one (or both) of the other two in a multi-factor authentication system. And a biometric/token MF system can absolutely be superior in security for many common threat scenarios and use cases compared to passwords. Achieving good security requires intelligent deployment of all 3.
Really? Please describe such a system. Will it use a photograph of the fingerprint? A hash value? What hash? How do you deterministically arrive at the exact same one each time, or do you plan to "change the user name every single time" and in that case what is the actual persistent pointer to the account/person? Do you expect people to then use that name in conversation or when they think about it?
See, this makes no sense. That's not what "user names" are, it doesn't have any of the properties humans ascribe to them.
>similarly, lots of applications use the fingerprint as both username and password
Name them. Name one, for that matter.
You seem very, very confused about all this but at this point I really don't know how to make it any clearer for you.
you are defining terms one way and i have defined them another way (that's fine) so that is why we cannot come to agreement on any corollary.
the distinction is that you are sticking to the "formal" definitions, while i am using "functional" definitions.
we agree (troll test #1) that auth factors can come in 3 flavors (for the 100th time): something you know, something you have, and something you are. according to this definition, a fingerprint goes into one bucket ("are") and a password goes into another bucket ("know"). peachy. BUT, fingerprints are also something else: GREASE. grease left on a handrail doesnt fit into any of these buckets. that doesnt mean its not a fingerprint!
do you see the point? if you can appreciate that, and look at my comments through this lens, they might make sense. functionally, programmers are free to use "usernames" QUA "passwords" if they want to -- we can't just define that out of existence.
and then about usernames: maybe you're just saying, hey i can't just swipe my finger at gmail.com because which gmail account am i logging into? do i need 1 finger for each account (business, personal, etc)? lol that's kind of valid point too but nobody is proposing that the biometric identifier is the only part of the username anymore than your browser fingerprint is (which google does indeed utilize; sign in from somewhere else and you'll get 2FA vs on your own device, etc etc). think of your biometric data more like your phone number in 2fa. its yours and can help to verify your identify but its not secret and your authenticator should be secret
Not very secure.