Fingerprints and Passwords: A Guide for Non-Security Experts | Hacker News Reader

Fingerprints and Passwords: A Guide for Non-Security Experts

xato.net

34 pointsm8urn11 comments

Firstly I see all biometrics as a username not a password.

I assert I am lifeisstillgood - and I enter my shared secret so that pg can make a reasonable assumption that the person he originally told the secret too has not shared it and therefore is at the other end if the transaction.

The problem with fingerprint recognition is it is a zero-factor authentication. What we have here is a very long username with say 44 bits of entropy(#). No matter how long that username, it's not a secret. I wonder around leaving it everywhere - just like "lifeisstillgood".

Without a shared secret, a username is not a sufficient security device - it's just what I am asserting - zero factor authentication is a problem.

(#) now this is an interesting issue. Fingerprints have been assumed to be 100% unique amoung humans. But with DNA fingerprinting came a confidence level, and now forensic scientists are resisting assigning confidence levels to fingerprints mostly I think for the apocalypse of having to review 30 years of convictions then made unsafe.

I'm glad someone is talking about this. If you set a passcode, iOS encrypts your data with a key derived, in part, from your passcode and a per-device salt; Apple claims that even with access to the device, a nine digit passcode would take 2.5 years to brute force. [1]

A fingerprint is only useful for authentication, not key derivation, which makes it effectively useless in protecting your secrets from a determined attacker. As it stands today, my data is encrypted with a key that isn't stored on my device. Unless Apple has developed some kind of fingerprint-based key derivation algorithm, that can't be the case for the hapless user who replaces his passcode with a fingerprint scan.

I fear that the innovation announced today is going to make people and their data less safe, not more.

[1]: http://images.apple.com/iphone/business/docs/iOS_Security_Oc...

"A fingerprint is only useful for authentication, not key derivation"

exactly

> Apple claims that even with access to the device, a nine digit passcode would take 2.5 years to brute force.

That's 2.5 iPhone-years of computation, though. A speedy desktop could be 10 times as fast, and that's before we get to GPUs or multiple machines.

I would make the following points.

1) Not accounting for salting and variations of hashes, one can have at most 19 resets of core biometric assuming the normal number of fingers and toes.

2) Biometric fingerprinting merely proves that you have the digit. No proof if said digit is attached to human (see Hollywood blockbuster!).

3) Susceptibility to coercion. It's much harder to refuse to swipe your finger (willingly or otherwise) at the border than to refuse to give up a password.

My counter to your second point: Biometrics kinda disables mass hacks. you cant exactly chop off a huge number of fingers*

Oh and one can also say "A password merely proves you know the password. No proof that you are the person associated with the password"

* Though since passwords can be stored in hashes, they can be harder to steal as compared to biometric data which must be stored in raw (though possibly encrypted)

Why would you need to reset biometrics (point 1)?

The equivalent of losing your password.

>Third party must have access to raw data

Is there a reason that fingerprints can't be stored as hashes instead of the raw data? It would presumably involve re-enrolling if the fingerprint comparison algorithm gets changed, but how often does that happen?

The problem is that fingerprint matching isn't exact, there are thresholds you must allow for so there is no exact code to match to. Although some implementations may make this possible, it is an issue that all biometric methods must address.

It's like allowing a password that is close enough, in that case you would need the real password as well, not just a hash.

Sure, though there are simhash implementations, where you can compute a hash that itself can be used to compute a hamming distance between two inputs.

(This is used a fair amount in search, to cluster similar documents.)

Reply on news.ycombinator.com