Biometric features are irrevocable

Let's assume you use getthereamazinglyfast as your password for all your email and social accounts (eg. Gmail, Facebook, Snapchat, Twitter, etc.). If Facebook were to get breached and all Facebook usernames and passwords were to get posted online publicly[1], all of your other accounts would be vulnerable because you used the same password everywhere. It's the same thing with using biometric data.

Except that, at this point you can still change your passwords for the other accounts[2], but not your biometric features. So once an auth system that uses your thumbprints (for instance) is breached, you're more vulnerable to every system that uses it.

This is why biometric data — just like the other authentication proofs — are not stored directly.

Data stored as a function

Biometric data is ideally stored as a one-way function of the original data; similar to how the hash of a salted-password is stored rather than the password itself. An important property of one-way functions is that they are not easily reversible.

For biometric data, it'll be something like this:

representation = f(biometric_data)

where f() is a one-way function which generally includes a feature extraction process.

Before biometrics can be used by a system, the person will have to go through an erollment process with the system when he inputs his biometric data (fingerprints for example) multiple times. The representations of this data is used to generate a template. This template is stored by the auth system.

The representation (and thereby the template) could be made revocable by including an additional transformation function t() which is analogous to password salting.

Now, the process of biometric authentication would be something like this:

Acquire the user's biometric_data on a trusted device.

Pass it to the one-way function f() to get the biometric_data's representation and get rid of the acquired biometric_data.

Check if the representation matches the stored template and return a yes/no result.

Neither the template nor the representation can be used to reproduce the original biometric_data since it was created using the one-way function f(). So, incase of a data breach, the original biometric data of the user is not lost to the attacker.

Here's a related thread I happened to come across on Twitter:For some context, this was in response to the iPhone X Face ID:

if it similar to touch ID, it doesn’t exactly know what you look like, as the data stored is more analogous to a hash of your face (kind of)

Now, though the original biometric data cannot be reproduced with the template, the biometric traits would still be retrievable. So as along as a transformation function t() is used, the template data won't be usable against another system using the same traits for feature matching. Here's a related discussion.
You may check the further reading section at the end of this post for a deeper understanding of the process and the possible attack vectors.

Speaking of attack vectors, if the 3 steps of the authentication process happen within the trusted device itself and the biometric authentication system is isolated from the rest of the device's systems, the only attack the app will be vulnerable to is fake biometric inputs fed into the device.

Biometrics in Android and iOS

Android and iOS both support biometric authentication via fingerprints and face recognition. However in both cases:

the auth system protects the device, not the identity.

the auth system is well isolated from the rest of the device: nothing other than the auth system itself can ever access the biometric_data or the template.

everything happens on the device itself: neither the template nor the representation ever need to leave the device.

So in the case of Android and iOS, the only way to bypass the biometric system is to fake a genuine input. And even if the attacker can fake a genuine input, he'll still need physical access to your device. The attack surface area is quite minimal.

On the other hand, biometric authentication is super convenient on phones. I never had a PIN on my old Android phone because I din't want to be typing it in everytime. But fingerprint authentication has changed that. Though I'm still made to type the PIN once in a while I seldom have to request people to look away while I'm typing the PIN.

Android does fall in a bit of a gray area though, because OEMs have considerable control too, so don't buy a device from a manufacturer you don't trust.

For everyone saying "use a passcode and not biometrics because otherwise the cops can force you to unlock your phone", I give you Exhibit A pic.twitter.com/0xRLpdcexp

2½ step authentication with Biometrics

A lot of sites have started to support 2 step authentication using a password and then a PIN (generated with a time-based algorithm or sent via SMS). I've written more about this and why it helps secure your account in a previous blogpost: Authentication and Identities.

Let's consider dropbox. The flow would be something like this:

Enter your email and password.

Enter the PIN generated by your TOTP app [or] enter the SMS sent to your phone.

Now if you have a lockscreen setup on your phone, you've got one additional step before you can complete step 2, especially if you use a TOTP app. And if he decides to use biometrics here, that one additional step could be so seamless that the real-user wouldn't even realize it.

Now I know there are ways around it depending on how the lockscreen is setup and if SMS texts show up on the lockscreen. That's the reason I'd call this a ½ step 😬

On the flip side, not having a lockscreen setup on your phone makes the second 2FA step ½ times less secure!

Biometrics in India's Aadhar

The Aadhar is a bit of a mess. You may authenticate via biometrics or an OTP sent to your phone. And then biometric feature matching happens at Aadhar's servers. And every device is trusted: users are forced to trust the device put in front of them.

Now one might argue that the Aadhar is not an auth system in the first place and I'll have to agree to that.

Conclusion

So, yea or nay? I'm all in for it.
As long as it's done right, of course. This is true for every kind of authentication anyway.

Facebook stores hashed passwords (like everyone should) according to this source, so the attacker would only get the hashed salted-passwords rather than the actual password. And I do believe that they're ready to face a breach when it happens ↩︎

Only if you happen to know about it though. So don't use the same password everywhere! And use a password manager. ↩︎