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?

9
  • 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 5 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. Aug 6 at 8:22
  • 4
    They won't. People who say they will are trying to sell snake oil. Aug 6 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). Aug 6 at 16:12
  • 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 9 at 18:25
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

14
  • 14
    That's a totally different set of questions that do not logically follow from my statements.
    – schroeder
    Aug 5 at 11:50
  • 6
    Of course we can move off of passwords. Moving to fingerprints, however, would be a challenge.
    – schroeder
    Aug 5 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 5 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 5 at 22:09
  • 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 6 at 6:08
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.

7
  • 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 6 at 6:01
  • Hmm, it also means that when you lose access to this device, you can't use this method of logging in anymore. Aug 6 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.
    – Ajedi32
    Aug 6 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 6 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: chat.stackexchange.com/rooms/128311/…
    – Ajedi32
    Aug 6 at 21:06
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").

2
  • 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 7 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 9 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.