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.
Using a fingerprint for authentication is like using one unchangable password for every system. Bad practice!
It doesn't have to be like this. All we need to do is make sure we keep talking.
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.
It means that biometrics should be the username, not the password.
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.
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.
Is that actually true, though? I thought law enforcement, at least, identified fingerprints via a series of distinctive "features" rather than a full image of the fingerprint. In theory, couldn't these features be listed as to their presence/absence and coordinates relative to the center of the fingerprint, creating a consistent hashable value?
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.
Let's not stir that bag of worms...
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.
Just pre-process them with something like SIFT to eliminate the variations introduced from one reading to the next and hash that.
Someone forgot to tell Apple that they're not hashable... because that's how they're storing them.
But then, you don't use them as a key to encrypt, you use them to *verify* that you are you. This takes care of dumb people trying to break into your phone. The smart ones just open up the phone and try to read the flash and security EEPROM directly.
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
Just ask the FBI if fingerprints can be hashed. They've been doing it for decades as part of AFIS - the Automated Fingerpritn Identification System.
In a nutshell: Software looks for minutae in the print - locations of whorls, loops, valleys, etc. Once those are located it decides where they are relative to each year, then puts those relative coordinates into bins. The smaller the bins, the less tolerance there is for variability like being squished hard against the scanner and spread out. If you set your bins too small then you'll get a bunch of false negatives. But you don't have to do just one set of bins - you can do multiple bins, progressively more precise and then put them in a search tree where the further you go down the tree the more confidence you have that the print is a match.
Those bins are effectively a password which can be hashed just like any other password and you can store hashed bins instead of originals in the clear if you want because you are just doing a bit comparison with each higher level of precision.
Same AC here: Disregard that, I suck cocks.
Most match protocols use point algorithms to store the points and patterns.
The fact that you've never seen this does not mean we don't have it. We just don't tell you.
However, all biometrics are highly hackable. Including and especially facial recognition.
The chief way to stop people is to pay attention to your actual vulnerabilities and concentrate on those, and vary the more easily defeated protocols.
Stop believing movies. Most of what you see in those are fake.
-- Tigger warning: This post may contain tiggers! --
... and this comment would give too few space to write down the beatiful proof?
... and this comment would give too few space to write down the beatiful proof?
No, but I see no point in giving it away for free.
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.
You can, at least, refuse to divulge your passwords.
File under 'M' for 'Manic ranting'
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. You still need to use a username when authenticating with a biometric. Biometrics work fine as authenticators but they work completely differently from passwords.
I went into detail here.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I am so tired of this over-hashed argument (see what I did there?). Fingerprints are not meant to be passwords, they are *secure usernames*. In other words they provide a username that no one knows or can figure out. As such they provide some security, but not to the degree of a good secret password. So by itself a fingerprint shouldn't be used for security. But, a fingerprint makes a good part of a multi-part system. In most cases a fingerprint and a pin is quite sufficient and much better than a known or obvious username and a typically poor secret password. P.S. Inferred handscans are even more secure than fingerprints, and given all the issues with passwords, are probably sufficient in themselves in most cases.
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.
And the worms ate into his brain.
Why not? I remember seeing an example of how to hash fingerprints something like 20 years ago. It may not work with the current fingerprint checking tools but it went something like this:
1. user (fingerprint owner) Generates a random image the size of the fingerprint image.
2. Add error correcting - e.g. an R-S code on the rows and columns
3. Hash this resulting data
4. XOR the image in 2 with the fingerprint.
5. Send 3 and 4 to the person who wants to verify the users fingerprint later.
(User might want to save a hash of 4 so that they can verify that when presented with this data again they can tell it hasn't been tampered with)
When the time comes to verify the fingerprint:
1. Verifier sends 4 above to the user
2. User XORs their fingerprint with 1
3. Apply error correcting to 2
4. Generate the hash from this data and send to verifier
5. Verifier compares with hash stored. aka password.
The challenges are related to detecting the rotation and position of the fingerprint when you don't save any data about the fingerprint itself. What you need is an algorithm that can consistently align a fingerprint by shifting and rotating a fingerprint when it's presented slightly differently.
There's also the challenge of getting the amount of error correcting correct. Too little and the random image recovery won't work. Too much and you'll start accepting fingerprints that are similar but different or allow brute force to recover the hash.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
That method will usually fail because fingerprints are deformable.
And I need money to survive. My knowledge might help me get money, by selling it.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.