21

Let's say Alice created a new account on a service and this service saved her fingerprint as a way of logging in later. Then Alice creates a new account on a new service, but unfortunately this second service is not properly secured and the biometrics data got leaked from their database, how will Alice use her fingerprint again in any other authentication if it is no longer a secret?

After this, anybody could attach her (leaked) fingerprint data in a normal API request to the service and impersonate her, is that right?

Am I understanding biometrics authentication correctly or not?

Reid
  • 103
  • 3
Mohamed Waleed
  • 1,169
  • 1
  • 5
  • 13
  • 10
    You never store or transmit Biometrics unless you want real trouble when your systems get breached. Biometrics should only be stored in a crypto-locker that belongs to your user. Alternatively you can use biometrics when only the results of mathematical/cryptological one way functions are stored/transmitted. – svin83 Aug 05 '21 at 23:39
  • 4
    The US military uses biometrics, and an armed guard next to the sensor so nobody tampers with it. Try to transfer that to remote attestation. – Simon Richter Aug 06 '21 at 08:22
  • @SimonRichter The biometric data isn't usually stored in the sensor itself. Typically all the sensors in a location are connected to a central server that holds the data. You attack the server, not the sensors. – Barmar Aug 06 '21 at 13:41
  • 4
    They won't. People who say they will are trying to sell snake oil. – R.. GitHub STOP HELPING ICE Aug 06 '21 at 15:05
  • 4
    @Barmar, the problem with biometrics is that the information can be captured and replayed easily, and is transferred in clear between the user and the sensor (e.g. a fingerprint is transferred as mechanical force here, and even if the sensor encrypts the data for transfer to the authentication service, that weak link remains). – Simon Richter Aug 06 '21 at 16:12
  • @SimonRichter I misunderstood your comment. When you said "nobody tampers with it", I thought you were referring to the stored data, not the authentication process. – Barmar Aug 06 '21 at 16:14
  • Well Alice has 10 fingers, doesn't she? And 10 toes for even more backup :-) – Matija Nalis Aug 06 '21 at 20:27
  • related: https://www.theguardian.com/technology/2014/dec/30/hacker-fakes-german-ministers-fingerprints-using-photos-of-her-hands – JimmyJames Aug 09 '21 at 18:19
  • 1
    @SimonRichter And the sensor isn't even the weakest link. People leave their fingerprints all over the place. Find your target, ask them to hold something for a moment. – JimmyJames Aug 09 '21 at 18:25

4 Answers4

23

When people talk about biometric authentication for the web, usually they are referring to the Web Authentication standard; a new, standardized method of user authentication which has been implemented in many popular web browsers.

The web authentication standard does allow users to sign into websites using biometric authentication (e.g. fingerprints), but it doesn't work the way you've assumed in your question. As you've correctly surmised, sending a copy of the user's fingerprint to websites for them to store would be terrible both from a security and a privacy perspective.

Thankfully, the web authentication standard does not work that way. Instead, it works by generating a site-specific private key and storing that key somewhere on the user's device. Then, when the user wants to sign into a site, their browser uses this stored key to prove the user's identity to the site using public key authentication, signing them in.

So where do biometrics come into this? Using the web authentication standard, it is possible for websites to request that the user's browser verify their identity locally before allowing them to sign-in using the stored public key. This local verification can be done using biometrics, among other methods. The W3C standards document explains:

6.2.3. Authentication Factor Capability

There are three broad classes of authentication factors that can be used to prove an identity during an authentication ceremony: something you have, something you know and something you are. Examples include a physical key, a password, and a fingerprint, respectively.

All WebAuthn Authenticators belong to the something you have class, but an authenticator that supports user verification can also act as one or two additional kinds of authentication factor. For example, if the authenticator can verify a PIN, the PIN is something you know, and a biometric authenticator can verify something you are. Therefore, an authenticator that supports user verification is multi-factor capable. Conversely, an authenticator that is not multi-factor capable is single-factor capable. Note that a single multi-factor capable authenticator could support several modes of user verification, meaning it could act as all three kinds of authentication factor.

Although user verification is performed locally on the authenticator and not by the Relying Party, the authenticator indicates if user verification was performed by setting the UV flag in the signed response returned to the Relying Party. The Relying Party can therefore use the UV flag to verify that additional authentication factors were used in a registration or authentication ceremony. The authenticity of the UV flag can in turn be assessed by inspecting the authenticator's attestation statement.

Since this verification happens locally on the user's device, there is little chance of the user's fingerprint information being leaked to attackers. Furthermore, since the fingerprint is merely an additional layer of protection for the WebAuthn key, an attacker who did somehow get a copy of the user's fingerprint wouldn't be able to use it to sign into their accounts without also having stolen the device the user's private key is stored on.

So to summarize: while biometrics alone would not be a good way to authenticate users on the web, the way it is implemented in practice is actually quite secure. Quite a bit moreso than passwords in fact.

Ajedi32
  • 4,637
  • 2
  • 26
  • 60
  • 5
    Leaking the fingerprint information is, in fact, completely irrelevant. Leaking the private key is the concern here, and the fingerprint is just a method of local authentication to access that key. – Jan Hudec Aug 06 '21 at 06:01
  • Hmm, it also means that when you lose access to this device, you can't use this method of logging in anymore. – Paŭlo Ebermann Aug 06 '21 at 17:46
  • @PaŭloEbermann Yes. That is, in my opinion, the biggest obstacle right now to the adoption of WebAuthn as a password replacement. It could be easily solved by encrypting the credential database and syncing it to the cloud (like password databases are), but so far browser vendors have [refused to implement that functionality](https://bugs.chromium.org/p/chromium/issues/detail?id=1031214). – Ajedi32 Aug 06 '21 at 17:53
  • @Ajedi At which point as soon as your biometrics are leaked (which they invariably will) not only is the system worthless for you, but you have also provided your attacker with a nice and easy way to get at all your credentials. – Voo Aug 06 '21 at 21:01
  • @Voo That's not at all how it would work. This is getting way off topic though, so let's take this to chat: https://chat.stackexchange.com/rooms/128311/webauthn-as-a-password-replacement – Ajedi32 Aug 06 '21 at 21:06
  • Dumb question: how is this supposed to prevent a user from using a "bad" browser that doesn't use their fingerprint to verify them. Some users for instance might think that fingerprint authentication is way too weak and prefer another means to identify themselves...or feel their device is physically secured enough to grant only them access etc. Is there an attempt to whitelist browser builds included? – Frank Hopkins Aug 07 '21 at 05:43
  • @FrankHopkins Any user in a position to be able to do that is already past the point of security that the fingerprint is for. – Douglas Aug 08 '21 at 02:59
20

  1. You are not incorrect. That is why biometrics are not typically used as the sole factor in authentication.

  2. Biometrics, like fingerprints, are not secret in the first place

  3. Biometrics are weak authentication since biology changes, fingers get removed/scarred/burned/etc.

  4. Biometrics for authentication usually require some other biometric factor besides the pure data

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • That means we cannot move off passwords. And the things we see in future-technology movies are far from being real. Right ? – Mohamed Waleed Aug 05 '21 at 11:40
  • 14
    That's a totally different set of questions that do not logically follow from my statements. – schroeder Aug 05 '21 at 11:50
  • 6
    Of course we can move off of passwords. Moving to fingerprints, however, would be a challenge. – schroeder Aug 05 '21 at 11:51
  • 4
    You are assuming that what is seen in movies is *solely* about the fingerprint pattern. As I say in my last point, biometrics are often *combined* to boost confidence in the factor. Like pulse, vein patterns under the skin, etc. – schroeder Aug 05 '21 at 11:53
  • 1
    @schroeder if I were to ask a question about potential methods to move off passwords entirely, could you answer/think it's acceptable for the SE? You've got me curious – TCooper Aug 05 '21 at 22:09
  • @schroeder That really depends on how you define ‘passwords’. For example, the ‘PIN’ thing that MS does for Windows account logins is functionally a password for all intents and purposes despite not being called such by MS. – Austin Hemmelgarn Aug 05 '21 at 22:14
  • @TCooper we already have some of those – schroeder Aug 05 '21 at 23:00
  • 1
    @AustinHemmelgarn typically we're talking about "something you know" – schroeder Aug 05 '21 at 23:04
  • 2
    Biometrics is often used as a sole (with alternative, but only one is needed at any given time) for *local* authentication. When it is used as part of remote authentication, it is only used to authenticate to *local agent* (like an authenticator app). – Jan Hudec Aug 06 '21 at 06:08
  • 1
    @JanHudec you are correct, but the context here is the imagined authentication process of the OP. Biometrics for the local device is different since you require physical possession of the thing you are trying to unlock. And I would argue that the process is not "authentication" but merely "unlocking". – schroeder Aug 06 '21 at 10:44
  • And unlike a password, you can't reset your biometrics if they are compromised! (Or at least I wouldn't want to!). – bob Aug 06 '21 at 12:58
  • @MohamedWaleed "the things we see in future-technology movies are far from being real" - I would take anything you see in a movie with a pile of salt and large degree of skepticism. Especially when it comes to security depictions. Movie writers are going for drama and excitement, not realism. – Seth R Aug 06 '21 at 16:32
  • @TCooper Search for "public key authentication" in Google and you'll find a good answer to your question to satisfy your curiosity. – niemiro Aug 06 '21 at 22:58
  • @niemiro sure, but a private key is still a password to the public key… it’s just a long randomly generated one we pass as an encrypted file instead of typing in, but falls into “something you know” imo - so I wouldn’t consider it forgoing a password, just a better version of a password – TCooper Aug 08 '21 at 00:21
7

Biometrics will never be a safe way to directly authenticate users across the internet.

However, they can be used securely as a part of a chain of trust that authenticates users as part of the chain.

This is how secure implementations work:

The user never authenticates to the internet service with biometrics. Instead, the user authenticates to a local device (fingerprint reader, mobile phone, ...), and then that device authenticates to the service. The service trusts the device to perform the user authentication.

Notice how the service never receives the biometrics themselves - so they can't be leaked through a service or database compromise.

You might be thinking: "but this just moves the problem to the device, it doesn't actually solve anything!". And you'd be right, to some extent. However, it turns out that in practice it's much easier to authenticate devices than it is to authenticate people. Devices:

  • Don't forget their password (key)
  • Can remember a much longer password than a human can

There's also other important security differences when authenticating devices instead of users. Devices:

  • Can be controlled by third parties (manufacturer, law enforcement, national security) to reveal information against the user's will
  • Can easily be uniquely identified and tracked
  • Can prevent the user from performing certain activities (for example, DRM)
  • Can be compromised by an attacker (although for the average user this is often harder than compromising a password)

Finally, you might be wonder how the device authenticates to the service in the first place.

There's many techniques to achieve that. They usually involve the device storing a secret key then using a authenticating cryptographic protocol.

The key is often asymmetric and might be stored inside a TPM ("trusted hardware").

loopbackbee
  • 5,308
  • 2
  • 21
  • 22
  • 1
    The distinction between authenticating to a device with a fingerprint, and authenticating to a service with a fingerprint, is that the device has a greater level of assurance that the fingerprint actually came from a fingerprint reader. Unless it's been tampered with, but then, tamper-proof devices do exist, but even if it's not tamper-proof, it might still be a sufficient roadblock for many attackers. – user253751 Aug 07 '21 at 12:02
  • @user253751 however it's comparatively trivial to "fool" fingerprint reader. So if the attacker has a physical access to a device, biometrics still loose to a good ol' passwords. – Dan M. Aug 09 '21 at 12:24
4

When you authenticate a fingerprint you are comparing the fingerprint to some previously stored data.

If every authentication service stored the same data, then a data leak by one service would compromise the others. Also if any service stored a complete copy of the fingerprint then that copy could be used to authenticate on any of the other services.

The solution is that each authentication service should only store a small percentage of the fingerprint data sampled at random, then the chances of using that data to authenticate on another service that was doing the same would be very small.

The reason is that the datasets stored on each service would have very little overlap since they consist of randomly sampled points.

Some balance needs to be achieved between sampling enough data so that the service doesn't erroneously grant entry to the wrong user, and not sampling so much data that it correlates with the data on other services.

The other option is that the authentication service doesn't store the actual fingerprint data. In the same way that many services only store the hash of a password (and not the actual password). Biometric data is going to be similar on each scan but not exact. Its possible someone could develop a special type of hashing algorithm suitable for comparing data that is similar but not exact. For example one where similar input data generates a similar hash, with the difference in the hashes being proportional to the difference in the data. The service would then just evaluate weather or not a hash of the scan data was close enough to the stored hash.

user4574
  • 443
  • 2
  • 6