A question we get regularly is which is most secure, a (short) PIN or a biometric as a second factor?
Neither on their own provides sufficient security, and hence can only be used a second factor. However, one cannot simply compare the level of security provided by a PIN or a biometric, as security is not one-dimensional. One can for example learn a PIN by observing the user inputting it (“shoulder surfing”), while this does not matter for biometrics. A PIN can be changed, however since you are your biometrics, it is not possible to change these in case of compromise. Let’s start by looking at each mechanism in detail.
A PIN (Personal Identification Number) code is typically a 4-digit to 8-digit code that a user needs to remember and input whenever authenticating.
A PIN code can thus be seen a low entropy password. There are 10.000 possibilities for a 4-digit PIN code, which means about 13,3 bits of entropy (213,3 ≈ 10.000). An 8-digit PIN code provides about 26,6 bits of entropy. Note that these are theoretical values, assuming the PIN codes are generated at random.
A study of leaked 4-digit PINs revealed that the 3 most picked PINs “1234”, “1111” and “0000” together account for 18,5% of these PINs. And just like with passwords, if one has some background on the user like e.g., their birthday or birthdays of loved ones, one will, on average, have an edge towards guessing which PIN was picked by that user. NIST Special Publication 800–63–2 (superseded) contained an entropty estimation for user-chosen passwords and PINs. A randomly generated 8-character password (containing small case letters, capital letters, numbers and special characters) has 52,7 bits of entropy. In contrast, one chosen by the user provides, on average, only 18 to 30 bits of entropy, depending on the enforced password rules. Similarly for PINs, when chosen by user, the entropy is estimated to be 9 bits for 4-digit PIN, adding 1 bit of entropy for each additional digit.
Note however, that is not per se a plea for forcing randomly generated PINs upon users. Users also need to remember their PIN and ideally not resort to coping strategies like writing their PIN down on a post-it and attaching it to the back of their device.
Given its low entropy, traditional brute-force protection mechanisms for passwords (i.e., hashing and salting) don’t hold up as an attacker can far more easily try all possible PINs. Therefore, limiting the number of tries is a must. Typically, the number of tries is limited to 3. To effectively limit the rate at which a user can try, you either need secure hardware or alternatively go online and verify the PIN server-side. Ideally in the online scenario, it should equally be impossible to brute force a PIN at the server-side. This can be done by secure hardware at the server-side or by deploying an interactive zero-knowledge protocol.
When PIN code verification needs to be done offline (without making connection to a server), the system’s PIN verification mechanism is to be preferred due to its built-in locking mechanism. Even though this built-in locking mechanism is typically not implemented in secure hardware, it will still be harder to circumvent than a pure software-based defense built into your app. The biggest downside of this approach is that you have no control over the system pin, you cannot set a minimum length, nor can you prevent the user from choosing a common PIN. In some cases, you can only ask for a device unlock, which could be a PIN, biometric or even something like a swipe pattern.
Next to easy guessing of user-chosen PINs (and passwords), these are also frequently re-used. PINs (and passwords) are sometimes shared with close friends or family. Both negatively impact the security.
Another issue of PINs (and passwords) is that these are relatively easy to observe when the user is inputting it (“shoulder surf”). It turns out that this is even more so than for passwords as PINs are typically shorter and each individual input of a PIN pad typically displayed larger than a keyboard.
PINs (and passwords) can be forgotten by the valid user, which means that a fallback, reset, or recovery mechanism needs to be in place. If these mechanisms provide weaker security than the PIN, this also negatively impact the security provided by the PIN.
No two biometric samples of the same person are the same. Opposed to verifying a PIN, fuzzy matching is needed to verify a biometric sample with the original biometric sample.
The problem with fuzzy matching is that it sometimes leads to errors, typically expressed in FAR (False Acceptance Rate) and FRR (False Rejection Rate). FAR is a measure for how often an invalid user is accepted, this rate thus has an impact on security. FRR is a measure for how often a valid user is rejected, this rate thus has an impact on usability.
Most biometric systems strive for an EER (Equal Error Rate) where FAR = FRR of about 1 in 50.000. For more information, see the Android, iOS and FIDO biometric requirements. Apple claims to have a FAR of 1 in 1.000.000 for its Face ID.
This means that for a typical biometric sensor, if one tries 50.000 biometric samples, on average 1 will be accepted. The biometric data itself might not be guessed, something that matches with the valid user’s biometric data is sufficient.
When looking at biometric systems, there are roughly three classes:
- system-provided biometrics, which are typically backed by secure hardware,
- software biometric offline verification, and
- online biometrics, where the biometric is verified with the help of a server.
Like is the case with PINs, only the first (secure hardware) and last option (online verification) provide adequate rate limiting protection.
For system-provided biometrics, the number of tries is typically limited to 5 or a multiple of 5 with a 30 second timeout after 5 wrong entries. However, due to implementation mistakes on Android and iOS devices, researchers showed that the rate limiting can be stretched to 15 and in some cases even completely bypassed.
For the online scenario, there should also be precautions in place to ensure that the server never learns the biometric. This is even more important than with PINs as a biometric cannot be changed and can contain sensitive personal information (e.g., age, gender, race, medical information …). That is also the reason why privacy legislation such as the GDPR requires explicit user consent in many cases for remote processing of biometric data and makes sure that there are fallback options for user that do not wish to make use of biometrics.
While “shoulder surfing” is not an issue for biometrics, some biometrics might very well be observed and recorded while inputting these. Next to this, with the coming of generative AI and the amount of biometric data available online (pictures, videos), especially for public figures, some biometric systems become easier to spoof. Google also defines a SAR (Spoof Acceptance Rate) as a measure for the security of biometric sensors in its Android OS, which should be below 7% for class 3 (strong) biometrics.
Even though biometrics cannot be shared among users, some systems allow to register multiple biometric samples, which make it possible to “share” biometrics with a limited set of users by enrolling biometric samples for each of these users. When systems allow for multiple biometrics to be registered, this also has an impact on the brute-force security. With every try the captured biometric sample will be matched with all registered biometric samples, roughly dividing the brute-force security by the number of biometric samples that are registered in the system.
The biggest advantage over PIN codes is that biometric cannot be forgotten. But even so, a fallback, reset, or recovery mechanism is still recommended as the circumstances for biometric capture might not always be ideal and biometrics change over time. The security of these mechanisms also needs to be considered.
Brute-force security wise, a typical biometric sensor is more secure than a randomly generated PIN of 4 digits, but less secure than a PIN of 5 digits. Even Apple’s Face ID is less brute-force secure than a randomly generated PIN of 6 digits. Compared to passwords, both PIN and biometrics provide less brute-force security.
Effective rate limiting requires secure hardware or online interaction. Without it, there is no brute-force security and hence no security whatsoever.
When allowing users to choose their own PIN, their brute-force security will, on average, go down and users will be more likely to re-use PINs. However, forcing a randomly generated PIN on users will impact how well users remember it and probably lead to (a subset of) users resorting to coping strategies like writing their PIN down. Given the far from uniform distribution of user-chosen PINs, checking that a user-chosen PIN is not too trivial is highly recommended.
When allowing multiple biometric samples to be registered in the system, brute-force security will go down with the number of registered biometric samples. For a typical biometric system with 3 registered biometric samples, the brute-force security will be about the same as for a randomly generated 4-digit PIN.
While users should take care when inputting their PIN that no one is watching, biometric do not suffer from that problem. However, recordings and generally available images and video might also give an adversary an advantage towards spoofing a biometric of a valid user.
While a PIN might be shared among users, biometrics cannot. However, some systems allow to register multiple biometric samples. This can lead to “sharing” a biometric among a small group of users by registering a biometric sample of each of these users.
For both PINs and biometrics, fallback, reset, or recovery mechanisms are recommended. These mechanisms also need to be considered when evaluating the overall security.
Leakage of biometric samples is far more problematic than leakage of PINs. While both potentially give access to many applications, a user cannot simply change their biometric. On top of that, biometric samples can also leak sensitive information about the user like age, gender, race, medical conditions ….
Finally, we would like to stress that when looking into upgrading security from username/password, neither PIN nor biometrics on their own can be considered sufficient. However, as a second factor, next to something you have, they do provide the extra in security and maybe even more importantly confirm the user’s presence as opposed to simply having access to the something they have.