Slashdot Mirror
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.
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).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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/
I think Apple just applied for or received a patent on doing this.
http://9to5mac.com/2015/11/05/iphone-panic-mode-touch-id/
Sleep your way to a whiter smile...date a dentist!
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.