Hacker News Reader

> Checking for a fingerprint match essentially means that the administrator of the device is present and authorises the action

No it means only that the fingerprints are present. Your finger can be cut or you might be forced to unlock the device.

Touch ID specifically requires a live finger. Other fingerprint readers might not.

You can also be forced to reveal or enter the password.

> Touch ID specifically requires a live finger.

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.

You are missing the "requires a live finger" part.

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.

> A gummy bear may be lifelike, but normally lacks a beating heart and circulatory system.

“Normally”?

Sure, everyone says they want humanely sourced gummy worms. But there’s still a niche market for that fresh worm with the gummy goo still coagulating.

Most fingerprint sensors that look for a pulse can be fooled by a gummy bear that has been sliced thin enough to allow the pulse to pass through, but thick enough for the ridges to be picked up. Think about something around a millimeter thick.

If this is the case, why does Touch ID unlock a device in less time than the gap between heartbeats?

No, it only means that the device reported a match; or, that a match signal came in on a certain hardware port (since the scanner may have been replaced, tamperered with, etc.).

Not necessarily, it depends on the implementation. On Apple's case AFAIK the fingerprint mach doesn't simply report a match but also provides the system with the key(which was stored in a separate system) to decrypt the data. You can't simply connect a bogus fingerpront scanner to an Apple device and access the system, in fact that's the reason why unauthorised repairs end up having the touch ID or Face ID broken.

Same on Android. Fingerprint is used to enable access to cryptographic key.

That's why I have an "assumptions" part. It doesn't matter though, it will depend on the implementation of the fingerprint scanner.

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.

I think accounting for scenarios where someone might want to cut your finger off to gain access to your device is covered under the thread modeling reply above closer to the parent comment. Which makes sense. If I'm a cartel boss, I'm definitely not using biometrics. But if I'm a college sophomore who doesn't have any nation state enemies, then biometrics is fine.

if they are about to cut off my finger, I'm pretty sure I will just tell them my sudo password of my local machine. at that point they can modify all they want on my laptop.

That was literally the second half of the sentence (which you left out, unless GP edited their post).

> Your finger can be cut or you might be forced to unlock the device.

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 negated all of your points with your clarifications of "assuming that..." why should one assume none of those are present?

Because that's how you model your threats? You assume things like someone won't be able to physically take your RAM and read whatever data they want, for example. If you can't assume that, then you implement measures against it like soldering the RAM to the mainboard.

Most of the time they aren't. And if they are you probably can't protect against the attacker.

From elsewhere on this thread: https://www.schneier.com/blog/archives/2015/08/mickens_on_se...

This was not a negation, but a helpful clarification of what assumptions are made in either case (and thus, what your threat model must consider).

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.

> assuming that their fingerprints are not copied by an attacker

> 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.

If you like, you can stop making assumptions and only do statements but that doesn't change anything.

>"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.

> "this action was authorised by a keyboard entry sequence matching the admin account prerecorded sequence"

"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).

:)

I don't store anything but it doesn't matter because it doesn't change anything. Simply modify the sentence to include the hash conversion.

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.

> Simply modify the sentence to include the hash conversion.

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.

> "fingerprint scanner says yes" does not imply "Alice is currently holding her thumb against the phone screen"

Which is why GP carefully qualified his statement that "administrator is present" with the appropriate assumptions.

Related: fingerprints can be hacked https://news.ycombinator.com/item?id=29306163

As can passwords

But you can change passwords.

And the biometric check is still password based, right? You can't use Touch ID until you've entered your password, and then it's only a convenience for a given time.

The point is that fingerprints may not mean the administrator of the device is present, in the same way that a password that cannot be changed also may not mean the administrator of the device has authorized an action.

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.

I think there are many cases where your listed assumptions about each (passwords and fingerprints) are agreeable, but one important difference makes passwords often superior: ability to change after a compromise. If your accounts get hosed because someone else can enter your password, you can start over and continue using password-based authentication; if someone else can enter your fingerprints, you start over and must not use fingerprints for authentication.

True. But unlike a password, biometrics often also act as a second factor in that they authorize a particular device and can’t easily be done remotely. Even if my fingerprints were compromised, I’d probably continue using biometrics instead of or in addition to a password. I’m a fan of Yubikey with biometrics, for example, because it’s an extra layer of security. Just don’t lose a finger or hand or you’ll never easily authenticate again…