Unhashable: Why Fingerprints Are Weaker Security Than Passwords (hackaday.com)

szczys writes: Fingerprints aren't terribly secure; you leave them on almost everything you touch. Many people won't realize that fingerprints can be captured and reproduced from casual photographs. It's actually worse than that. The very method with which fingerprints are stored is much weaker than passwords. Fingerprints cannot be hashed. By their very nature, each read of your fingerprint will be a little different, which breaks the hashing method. They can only be stored using encryption, which requires the same master password each time a new print read is compared to the stored key — a much weaker method than salted hashes. This more easily opens fingerprint credentials up to theft and brute forcing.

Comments

Bad practice.

[Aethedor]

Using a fingerprint for authentication is like using one unchangable password for every system. Bad practice!

Re:Bad practice.

[jafiwam]

Using a fingerprint for authentication is like using one unchangable password for every system. Bad practice!

Not to mention fingerprint authentication or encryption is not Fifth Amendment protected.

Re:Bad practice.

[DaHat]

You can't, but interesting things may be able to happen if you fail to disclose which finger will unlock the device.

Maybe your right ring finger is what you use to login, but not having specific knowledge of which finger you actually use they have you try your thumb pointer finger... not knowing that your device treats that as a panic button and not only wipes out memory of the old finger print, but also remaining hope of them unlocking the device with or without your help.

Re:Bad practice.

[swillden]

Using a fingerprint for authentication is like using one unchangable password for every system. Bad practice!

Complete nonsense.

You're equating fingerprints with passwords. They're not passwords. Password security derives from the secrecy of the password. Anyone who knows the password can enter it, but we presume attackers can't enter it because they don't know it. Fingerprint security derives from the difficulty of presenting the known value to the sensor. Everyone knows your fingerprint (you leave them everywhere!), but we presume attackers can't enter it because they only have a picture of it, not a finger with it.

In practice, making fake fingers is not terribly hard. But shoulder-surfing PINs is even easier. Which is more secure? That depends on who you're trying to protect your data from. The FBI absolutely will make fake fingers and unlock your phone, but they may not have an opportunity to shoulder surf a PIN. Advantage: PIN. Your suspicious girlfriend probably won't make fake fingers, but has ample opportunity to shoulder surf you. Advantage: fingerprint.

Which is better for you? You decide.

In practice for most people the choice isn't between fingerprint or password, it's between fingerprint or nothing, because a password is just too inconvenient. Advantage: Fingerprint, by a very, very large margin.

Re:Bad practice.

[tlhIngan]

And Apple actually treats fingerprints as less secure - the real reason you have fingerprint readers is because it lets you be more secure than the default no PIN or passcode on your phone. The problem of this is human - the typical use case for a phone is you access it thousands of times a day for a few seconds each time. Entering a PIN or passcode makes it so much less convenient that much fewer people (less than 50%) actually do it. But a fingerprint that can be read while the phone is waking up means it's ready to go when you are, and you can have a passcode because that goes out of the way most of the time. Even better, it can be a complex passphrase that you type out - if you're only doing it a few times, it's a lot less inconvenient.

And that's why Apple justified the use of the fingerprint reader - it's less secure, but it's also way more convenient, and if you're not entering your password 1000 times a day, you're more likely to use it. Of course, some people go overboard with their passcodes...

But Apple also realizes the fingerprint is not the be-all end all, hence the rules where if you reboot the phone, or not use it for 48 hours, Apple demands you enter the passcode. The passcode still rules, and if the fingerprint reader goes awry, you can still unlock with it.

Re:Bad practice.

[Applehu Akbar]

Your fingerprint is the best password you will actually use. I do residential IT services in an area heavy with retired people, and the biggest problem I face is forgotten passwords. It's not supposed to be good advice, but I tell all of them to write every password down in at least two non-obvious places, because otherwise they will be forgotten. I keep running into users who have no machine password, or "12345" because "I wouldn't remember it!"

Better you think of a good password, and write it down.

Re:Bad practice.

[swillden]

Any device that can perform different actions based on different finger prints?

None are on the market that I'm aware of. iOS and Android both intentionally avoid distinguishing between different enrolled fingers, because the average user would find it very confusing. I don't know if Microsoft has done the same for Windows phone, but if they haven't they were remiss in their user testing, or they'd have discovered the same issue.

It seems likely that some future alternative Android ROMs will provide this feature.

Re:Bad practice.

[DaHat]

Any device that can perform different actions based on different finger prints?

And how many is that? Somehow I don't imagine Apple building such an explicitly anti-law enforcement feature. Maybe with a sufficiently jail broken device you could rig something.

Any multi-user OS which supports a finger print reader for log-in is an easy candidate to do this yourself. You have your normal account, one or two for the kids and your spouse and one for your dog fluffy... one of which you have bound to your panic finger, which when logged into for the second time (the first being when you configure it) it executes a script or three which clears the TPM, overwrites a few key sectors of the HD and then reboots.

Re:Bad practice.

[alvinrod]

Actually they're about a year and a half ahead of you apparently: http://www.macrumors.com/2015/11/05/apple-patents-touch-id-panic-mode/

Re:Bad practice.

[Mashiki]

Is this the case? I mean, every time I put my phone in my pocket, it cleans off my screen including the fingerprint sensor. I do that explicitly too, at least once a day too.

Sure, since you probably forget to clean the underside of the back panel and battery as well. Your fingerprints are likely on there somewhere, and if someone really wants your print and device and you are careful they'll likely follow you and wait for you to leave something behind that'll give a great print. Like a piece of paper, glass, can, other portable hard surface or even go digging through your trash for it.

Fingerprints are a shit security measure.

Re:Bad practice.

[davester666]

I think Apple just applied for or received a patent on doing this.

http://9to5mac.com/2015/11/05/iphone-panic-mode-touch-id/

Re: Bad practice.

[swillden]

You can do this with any rooted android device and tasker.

No, it would require changes to the system, because the fingerprint subsystem doesn't expose the finger ID to the framework. The HAL API reports the finger ID to fingerprintd, but that doesn't report it further up the call stack.

So you'd to modify fingerprintd to return the finger ID, change the Binder API between fingerprintd and the framework, and modify the framework to report it as well. Or I suppose you could hack fingerprintd to write the last-authenticated FP ID to a file and then allow apps that want to know which finger was used to read it. That would involve poking a few other holes in the security architecture, but would be the easy brute force way.

And the first thing anyone who cares about security does with an Android device is root it and install their own ROM that is free of carrier encumberances and spyware.

Or just buys a Nexus device and (optionally) refuses the various questions asked during setup about providing data to Google.

BTW, be very careful with rooting, and I recommend absolutely refusing any rooting solution that involves disabling SELinux. It's up to you, but poking large holes in the security model does significantly damage your device security.

Fingerprints are public information

[NotInHere]

They aren't some super secret thing you try to keep secret from everybody. You not just leak your DNA everywhere, you leak your fingerprints too. And unlike passwords, you can't just simply change them.

Re:Fingerprints are public information

[swillden]

They aren't some super secret thing you try to keep secret from everybody. You not just leak your DNA everywhere, you leak your fingerprints too. And unlike passwords, you can't just simply change them.

Correct. The security of fingerprints, like all biometrics, derives not from the secrecy of the data (because it's not secret, particularly not your fingerprints), but because of the difficulty of providing someone else's data to the sensor.

In an ideal world, with a sensor that is able to distinguish with 100% accuracy whether the finger (or whatever) it's being presented is real, live and attached to the person who is trying to authenticate, that would be really hard. In the real world, with the sensors on typical consumer devices, and in an unsupervised environment (i.e. no security guard watching to check that you aren't trying anything funny), it's really not very hard at all. Anyone who cares to can watch a YouTube video, spend $20 at the local hobby shop to get the materials, and spend a couple of hours turning an image of a fingerprint into a gummi finger which will fool most sensors. However, that doesn't mean it's worthless. It only means it's worthless against someone who is willing to do that.

Compare this to a more common mobile device authentication method: a four-digit PIN. It's rather easy to shoulder surf a four-digit PIN, especially with the assistance of smudges, and particularly if you're a friend or family member of the target. In practice, friends and family members are the most common unwanted intruders on mobile devices. Against a typical person, who isn't likely to mess around with lifting prints and manufacturing fake fingers, a fingerprint -- weak as it is in absolute terms -- is stronger than a PIN or Android pattern.

Even more important, many people find a PIN, pattern or password simply too cumbersome to use. Android's Smart Lock helps, by enabling the device to apply rules to determine when the device has probably not left your possession and to stay unlocked longer in those cases, but even that's too inconvenient for many. So that majority of mobile device users (on devices without FP scanners) don't use any lockscreen at all.

Having no lockscreen is far less secure than fingerprint authentication, in case anyone is unclear about that.

Thus, for people who would otherwise use no security, the extreme speed and convenience of a good fingerprint scanner makes it feasible to protect their devices. That's a big win for those people, even if someone messing with etching compounds and wood glue can get past it.

IMO, the biggest problem with the current crop of mobile fingerprint sensors isn't the devices, sensors or software, it's the users' perception of them as very high security. They're not. They're relatively weak, but highly convenient security. As long as people don't expect too much from them, they're awesome.

So, the bit about fingerprint template storage security is much ado about nothing. The new Android fingerprint subsystem (which I worked on) does a decent job. Templates are encrypted with keys that are inaccessible to the Android OS and kernel, and the matching of livescans against templates is likewise done where even a completely-compromised kernel can't alter or interfere. But that's actually not because templates are highly sensitive data. It's partly just good security hygiene and partly because the hardware-backed keystore can rely on fingerprint authentication to unlock secrets, and it doesn't make sense for it to simply trust the regular Android OS... since the reason that stuff is done in the secure context is so that compromises of the regular OS can't muck with it.

Re:Fingerprints are public information

[swillden]

I don't understand one thing. You mention that the matching of livescans against templates is done in an area which can't be altered or interfered with. And yet, at some point that hardware (I'm assuming it's all hardware) must send a positive signal to the software that it's OK to unlock the screen.

Yup.

Surely I could compromise the code that accepts that signal to simply always be a positive signal?

Certainly... except for other code running in the area which can't be altered or interfered with.

This is the reason that Android 6.0's fingerprint matching is required to be done in the Trusted Execution Environment (TEE), because that matching signal is used not just by the regular OS to unlock your screen, but also by other code in the TEE to unlock access to cryptographic keys which are presumably used to protect the most important stuff on your phone.

For example, using the new features in Android Marshmallow's hardware-backed keystore (especially this one, your bank's app could set up an ECDSA signing key that is used to authenticate to their servers, providing access to your banking information. That key could be configured to be unlocked by your fingerprint. If the fingerprint matching were provided in the regular OS then any compromise of the regular OS would enable access to your bank account, because the TEE-based ECDSA key would be relying on a signal from the regular OS to tell it to unlock the key. But because the TEE-based ECDSA key relies on a signal from the TEE-based fingerprint matcher, a compromise of the regular OS won't get the attacker in to your bank account (not unless you're around to put your finger on the scanner).

FYI, for Marshmallow the password authentication has also been moved into the TEE, and TEE-based keys can also be access controlled with password auth. So your bank could do the same sort of thing, but require you to enter your device password rather than present a fingerprint.

Or am I completely off base here?

Nope, what you said made perfect sense, you were just missing some pieces.

I should mention that for Android 6.0 the Compliance Definition Document (which specifies what it means to be Android) makes all of the TEE stuff "strongly recommended", but not "mandatory" for Marshmallow devices. However, it is all mandatory for devices that have fingerprint readers. The CDD also warns that it will become mandatory for N. In spite of not being mandatory for Marshmallow, though, it looks like nearly all major device vendors will have the new TEE stuff in their new devices (those launching with Marshmallow).

Re:What does this mean for biometrics in general?

[Anonymous Coward]

It means that biometrics should be the username, not the password.

It doesn't matter...

[beelsebob]

The question isn't "is a fingerprint more secure than a password", it's "is a fingerprint more secure than no security". Most phone users didn't have any password on their device. Adding a fingerprint secured those devices.

Fingerprint are not passwords

[throbber]

Fingerprints, in fact all biometrics, are not passwords -- they are usernames.

In the 'perfect' security combination of { something you are, something you know, something you have }, they are the "something you are" part.

Premise is not necessarily correct.

[JMZero]

It's more awkward to hash a fingerprint than a password, sure, but it's certainly not impossible. An image of a fingerprint is mutable and "analog" feeling, but you could, instead, base your fingerprint comparison on a more "digital" digest of information from that fingerprint (eg. you boil image data down to bits that are repeatable in the face of repeated scans, like you check whether feature X is significantly more prevalent than feature Y in this print).

It'd be tricky, sure, and potentially impractical given current scan quality - but non-hashability is not some inherent limitation of fingerprints or biometrics in general.

Naive analysis

[Anubis IV]

The whole suggestion that fingerprints cannot be hashed or are unhashable is rather preposterous. The author points out that a tiny flaw in a fingerprint can result in the hash being different, and he may very well be right that that happens, but that's an implementation issue, not an inherent problem with hashing fingerprints. After all, if you're doing things properly, you won't be hashing the raw raster scan of the fingerprint itself, but rather a normalized/filtered vectorization of the fingerprint that can be trained to ignore slight discrepancies like those.

Will it be perfect? Nope. Will it allow for mismatches (i.e. hash collisions)? Absolutely, but if you implement your normalization/filtering properly the hash collisions should only occur once in a blue moon, just the same as they do with normal passwords (e.g. Apple says the chances of a random match are 1 in 50,000 with Touch ID; see page 8 of their iOS Security document).

When you get down to it, this problem isn't much different from how YouTube or Shazam do their content matching, namely, they can take some sort of noisy data, apply a set of filters, generate a hash/fingerprint of the relevant data, then do a quick search based on that hash, rather than trying to actually match the noise in the coffee shop I'm in against the millions of tracks they've sampled. There are differences between those problems and this one, to be sure, and simply encrypting the fingerprint instead of hashing it does make things a LOT easier to implement (e.g. Apple doesn't hash fingerprints, but they do take the extra step of discarding minute details that would be necessary to reproduce a fingerprint before they encrypt it for later use), but to suggest that fingerprints are unhashable just seems silly. We're in the early days of fingerprint scanners in widespread use, and I'd expect that things will head in that direction with time.

Re:What does this mean for biometrics in general?

[glenebob]

You don't think it has anything to do with an utter pain in the ass it is to keep track of user/password and private/public key pairs, vs how simple a bio-scan is?

Bio-scans are easy to understand in practice. You walk up to a thing and touch it/look at it, and you're in. That's the appeal.

Even worse....

[mark-t]

.... there is absolutely nothing that you can actually do, barring the use of what would probably amount to excessive physical violence, to prevent someone from taking your fingerprints who is intent upon doing so.

You can, at least, refuse to divulge your passwords.

So I know something about this....

[FrankSchwab]

Finally, a slashdot topic where I can be informative. Disclaimer: I work in the industry building fingerprint sensors.

Fingerprints aren't perfect security. As so many others have pointed out, you leave them everywhere. That doesn't mean that they're not useful.

1. It's extraordinarily difficult to create a fingerprint spoof from a latent print. Yes, there are people who can do it - I can do it - but it's not easy. Notice on the videos of breaking into the iPhone 5s or 6 that latent prints are taken from a single fingerprint placed carefully on a squeaky clean screen. On your average phone, not so much. Someone who picks up my phone off the seat in a subway will be incapable of breaking in - unless I've just cleaned the screen with windex and carefully placed my fingerprint on it.

2. A fingerprint on a phone makes an excellent two-factor authentication system. The average hacker in east Elbonia can't break fingerprint security - because they don't have my phone or my fingerprint.

Perfect? No, but strong? Yes.

Re:What does this mean for biometrics in general?

[swillden]

I wish I wasn't an AC here, but dang it, I felt the need to respond.

It means that biometrics should be the username, not the password.

No. This is just as wrong as viewing a fingerprint as a password. Biometrics make lousy identifiers.

What? They make fine identifiers, when compared to the other option, entering your user name or id into a box. It's perfectly fine to view some biometric data as user identification.

Nope. You're wrong.

The birthday paradox is deadly to biometric identification on large-scale systems. It's okay on small systems with relatively few users, but scale it up and it simply doesn't work unless (as many systems do) you also apply some other disambiguating information, like a phone number or an identifier of some sort or statistical modeling to narrow the set of likely candidate templates. Well, unless you're okay with lots of false positives. Put 50K people in one system and identify them by fingerprint only, and virtually anyone who walks up will be identified as someone, and many people in the system will frequently get identified as someone else.

It's not fine to view that same data as authentication, simply because it doesn't prove the user is who he claims to be. The biometric data says "this is who I claim to be", something else needs to be there to say "and this is how I can prove it".

Nope. Assuming you already have a claim of identity (i.e. a username), a biometric provides a decent proof of that identity. How strong that proof is depends on the context and the procedures. For an extreme example (from a system I actually built), if there's an armed guard examining your finger for evidence of fakery, then it's actually very strong. On a mobile device, not so much, but it's still useful. See the other post I linked.