Also I don't see how compromising that hash is a problem in practice, if that ever happened. If it's salted it's worthless, but even if not, I don't know how you'd reasonably physically use it to hack into another fingerprint reader anyways.
When it comes to fingerprints you must assume that the attacker has the ability to control the scene and the ability to retry until successful.
The point is that reader has those preserved and stored somewhere, while fingerprints that a person just leaves about by going about their day are not. Just the fact that they are stored is an issue. Note, this is a response to the original question of 'pfft, a person leaves fingerprints all the time anyway'.
Again, the comparison is just not apt.
nb iPhone Face ID has additional protections, like each scanner using a different random physical pattern so hashes can't even be transferred across devices.
In other words, I am willing to buy an argument that Apple's implementation is better than some other implementations out there, but it does not apply to this case, because it was not Apple's Face ID that we are discussing.
https://www.theverge.com/2015/8/10/9126027/htc-fingerprint-s...
Similarly, a vendor of facility access control systems left fingerprint scans in an exposed ElasticSearch instance:
If an attacker had a fingerprint and wanted to figure out who it belonged to, they could hash it and compare the hash against a database of leaked names and hashes. Salting doesn't prevent this, unless the hash is intentionally slow, in which case the attacker would merely be slowed down.
Also, how much entropy is in a fingerprint anyways? If it's low, an attacker could generate every possible fingerprint and hash it to build a mapping from hash to actual fingerprint.
Since humans only get one set of fingerprints for life, fingerprints should only be stored and compared on secure enclaves on your own devices (like iPhones). It's way too risky otherwise.
This exactly!! QFT!
No biometrics should ever be used for shared or public devices! Biometrics are fine for personal devices that are always with us, and not shared by others, especially anyone outside our family/household.
I've made my peace with biometrics as far as unlocking my phone via fingerprint. My threat model is such that a fingerprint lock is often safer than pecking in a long password. (Because I'm often surrounded by shoulder surfers.)
So yeah, if a restaurant is forcing employees to scan fingerprints (or retinas or DNA or saliva or what have you) on public or shared devices for purposes of clocking in, or payroll, or whatever, then that is wrong and a perversion of biometric authentication. The company would be much better served by a correct application of security techniques.
And yes, if this means going back to passwords for awhile, then so be it. Passwords are a good first-line auth measure for shared devices that are not open to the public (let's assume that this restaurant's devices were only physically accessible by employees in the back office or something.)
Another idea is to let the employees authenticate using their smartphone. My bank has something set up with this. You install a smartphone app, it authenticates you, and it vouches when you set foot in the bank so that the teller already has your account pulled up. Then, in terms of biometric locking for the smartphone, knock yourself out; the company has no need to collect the data, just interface to an app.
Presumably they would have checked if their policy was legal before implementing it too. The problem is that they haven't really earned the presumption of diligence in this matter.
Every month or so there's another horror story on HN about some company storing passwords as plain text.
Just because something can be done right does not mean it is done right.
You essentially have N different hashes and require at least N - M (M < N) matches.