> Blanket statements like that are never true.
Except in cases where they are, like this one.
Just cause you want convenience doesn't change the fact your fingerprints aren't good passwords.
Except in cases where they are, like this one.
Just cause you want convenience doesn't change the fact your fingerprints aren't good passwords.
For the vast majority of users, the threat model looks like "I don't want that creep who just stole my purse to be able to log in to my iPhone", not "I am guarding state secrets and a potential target of Kremlin agents".
Passwords get stolen and used all the time, but I have yet to hear stories of everyday thieves breaking into iPhones with stolen fingerprints.
Checking for a fingerprint match essentially means that the administrator of the device is present and authorises the action, assuming that their fingerprints are not copied by an attacker and they are not physically forced to comply with an attacker.
Checking for a password match essentially means that the administrator of the device might or might not be present but authorises the action, assuming that the password was not obtained through a post-it, coercion, phishing, guessing or any other password extraction method and they are not physically forced to comply with an attacker.
If a credential cannot be changed then its confidence as an identifier is significantly reduced.
Fingerprints are useful in cases where the effort of copying a fingerprint is greater than the value of the target. They're great for almost everyone with low value systems, like your average easily pickable front door lock. They're good for keeping honest people honest.
Fingerprints are a problem for high value systems.
Fingerprints are also certainly a shared secret identifier, and we typically call shared secret identifiers "passwords" even when they aren't literally a typed word.
Namely: if you are forced to comply, it doesn't matter in either case.
If your password can be "obtained through a post-it, [...] phishing, guessing" etc. (key logger), then you might be better off with biometric authentication.
If your fingerprint can easily be extracted (and the sensor be fooled by it easily), then you might be better off sticking with the password.
Those clarifications give you a good way to think about the tradeoffs.
From elsewhere on this thread: https://www.schneier.com/blog/archives/2015/08/mickens_on_se...
No it means only that the fingerprints are present. Your finger can be cut or you might be forced to unlock the device.
The gist is, a password and a fingerprint are not the same thing. Fingerprint is not a weaker password or anything like that, they have different properties and as a result they have different pros and cons. For example, no one can copy your fingerprint by looking over your shoulder - unlike a password.
How common is this scenario? I imagine it is a lot less common than passwords getting stolen or cracked.
Contrary to how some people here are acting, most people aren't targets of foreign foreign espionage.
You can also be forced to reveal or enter the password.
I remember reading about one school which implemented "live finger" readers.
How did kids hack it?
Polymer clay and a gummy bear.
Put your finger on clay and wait for it to dry. You will have your permanent mirrored fingerprint.
When required fingerprint press gummy bear against clay and then against the reader. As gummy bear holds charge, can even be cut thin etc. there is little chance to detect that it is not a real skin.
The biometric system (sensor + algorithm) used by Apple, as well as other competitive biometric vendors, detect blood flow, pulse in the finger. This is done as a mitigation against fake fingers as well as the (always presented) gory "cut off the finger" attack scenario.
A gummy bear may be lifelike, but normally lacks a beating heart and circulatory system.
“Normally”?
> assuming that the password was not obtained through a post-it, coercion, phishing, guessing or any other password extraction method
If we're happy to make such assumptions, then we can remove security entirely: just assume that actions are authorised!
Less tongue-in-cheek: we should try to avoid making such assumptions in the first place. For example, saying "this action was authorised by the presence of an administrator" is setting us up for failure: that's a hard thing to ensure, and also relies on fuzzy concepts like "presence".
Instead, there's nothing wrong with saying "this action was authorised by the fingerprint scanner matching the admin account": it's a more accurate statement, it doesn't hide any vulnerabilities, and it doesn't rely on any fuzzy concepts; e.g. we're not talking about humans, fingers, etc. we're only talking about accounts and hardware devices.
>"this action was authorised by the fingerprint scanner matching the admin account"
Okay, so? It's the same thing as "this action was authorised by a keyboard entry sequence matching the admin account prerecorded sequence".
How is this any more useful? If anything, you better know and understand your assumptions and introduce other measures if you suspect that some of those assumptions are no longer true.
"keyboard entry sequence" is just a long-winded way of saying "password"; there's nothing wrong abbreviating.
However, even this facetious example was useful, since it's exposed a security problem: you're storing passwords ("prerecorded [keyboard entry] sequence"). You should be storing password hashes instead (using a slow hash function).
:)
The storing password part is relevant for extraction of password from an already compromised system and fingerprints can be hashed just as well(and on Apple's implementation, they are). It's just irrelevant implementation detail that doesn't make difference for the security of the system in question.
In fact, fingerprints are actually more secure because you don't have rainbow tables for hashed fingerprints but you have it for passwords.
You seem to be missing my point: that it's better to think about security issues in terms of the components and actions that actually exist in the implementation (e.g. "when the given password agrees with the stored hash, then XYZ"), rather than the real-world concepts they're crudely trying to approximate (e.g. "when the administrator is present, then XYZ").
If you want to use fingerprint scanners as part of a security system, that's fine; I really don't care. What I do care about is that "fingerprint scanner says yes" does not imply "Alice is currently holding her thumb against the phone screen", or other such real-world scenarios.
Alice holding her thumb against the screen might cause the fingerprint scanner to say yes; and it's perfectly fine to make that assumption when designing a UI (where failure is mostly an irritation). Yet security design should not make that assumption, since it may hide all sorts of vulnerabilities.
As an analogy: a "Keep off the grass" sign is not the same as there being nobody on the grass. It's good enough for something inconsequential, like turning on a sprinkler system (if you get wet, you should've followed the sign; similar to a UI breaking if the user doesn't use their phone in standard ways); yet it's not enough to, say, store our valuables on the grass, in the hope that nobody can get to them.
Which is why GP carefully qualified his statement that "administrator is present" with the appropriate assumptions.
You're technically right that fingerprints aren't "good passwords", in fact they are not even passwords at all. But for most people, most of the time, they cover most of the same use cases at a better convenience price point.
For general use (i.e. unless you work in security or journalism) that's what matters.
Mark Twain once said "All generalizations are false, including this one."