Hacker News Reader

Comment by robtoo | Hacker News Reader

Unfortunately, this doesn't solve the problem:

To do iris-scanning security, there must be a back-end database with the characteristics ("fingerprint") of each user's iris.

This database will be secured as strongly/effectively as a password database because it contains authentication credentials.

Unfortunately, password databases get broken into, and similarly iris databases will also get broken into.

The attacker then has to simply convert the iris fingerprint back into an image to replay to the authentication process.

This is probably easier than reversing a password hash (because the fingerprinting algorithm is unlikely to be optimised against reversing), and certainly no harder.

(This is assuming untrusted client-side hardware.)

View on HN

Ideally, you wouldn't store the iris fingerprint itself - that's just as bad as storing a cleartext password today.

Rather, a good solution would involve deriving a (site-specific) token from the fingerprint and handing it off to the remote service, which then deals with it in much the same way we expect sites to deal with passwords.

This, of course, presupposes that we can retrieve a consistent and unique fingerprint from the same iris from various different images of it, and breaks down if all we can do is check an iris image to see if it matches a fingerprint.

The problem with biometrics is that once they are faked, and they can all be faked, You Have Lost. Once I've managed to acquire a picture of your iris (and somewhere in the system one must exist, even if you hash it ASAP I can still grab it straight from the camera if I've hacked your box), what will you do?

Biometrics are pretty much useless in consumers hands; they're more security theater than anything else. I do mean "pretty much"; if you fiddle around the edges of the problem you can with some work construct a use case where they really are the best solution to a problem, but as something that can just be deployed on a wide scale for general purposes? No.

You appear to be suggesting that the real security benefit would come from off-loading the authentication process onto a third party, but we can already do that with password authentication by using OpenID / Facebook Connect / whatever.

It's not clear how using iris fingerprints rather than passwords really adds anything other than to increase the risk of a false negative, and introducing a third party dependency.

(I do take your point about storing a hash of the iris fingerprint, though. How this would intefere with the matching process is, I guess, outside of both our areas.)

The real security benefit, I guess, is that people don't need to remember any passwords. The biggest weakness of password schemes is that most people choose weak passwords that they can remember, rather than strong passwords. If you could consistently derive a password from biometric data, then that sidesteps the entire issue (there are no "weak fingerprints").

And if you could consistently derive the key from the biometric data entirely on the client, then you wouldn't even need an authentication provider, instead transparently treating the resulting authentication token as a password.

If you use a biometric fingerprint instead of a password you will soon find that passwords can be changed, but biometrics can't.

If a password database is compromised, you have a problem, but you can change everyone's passwords.

If an iris database is compromised, you really have a problem.

Biometrics are also susceptible to replay attacks, where sort-of-alternatives (such as tokens) aren't.

Which is why, as I mentioned, you don't store the biometrics. You don't even send them to the remote service.

Hash + Salt on the client, submit the result. Unique salt for each remote service, and you can change it for a particular remote service if it turns out they do stupid shit with it.

Reply on news.ycombinator.com