What is a biometric authentication?
Since we want to level the playing field, I’ll start with the seemingly obvious, making sure we are on the same page with semantics. There are three main authentication factors out there: something you know (e.g. password), something you have (e.g. a physical key) and something you are. And it’s the third one that defines biometrics. In principle ‘something you are’ is so unique, it has been deemed the strongest factor of all. Examples may be your face, fingerprint, retina, voice or one day maybe even DNA (a stretch of imagination, I know).
For many, many years biometrics indeed were the strongest of all factors, but the status quo was sort of challenged with the introduction of generative artificial intelligence and machine learning. For a moment I started thinking that the possession factor is in fact now safer than the evaluation of biometric characteristics. More on that later when I’ll talk about the risks that the newest technology poses to biometric comparisons.
This blog was a challenge for me, as I failed to structure it in a way that logically would be expected. I need to take you on a ride and move from one topic to another and then come back to the start. For that, I apologise.
Client Side, Server Side?
We are all very familiar with FaceID or TouchID on our phones or laptops. After all it’s biometrics, right? Only my face can unlock my phone and only my finger should match the TouchID on my laptop. There are two main types of biometric authentication, categorised by a virtue of the fact where the decision is made whether the sample matches the original.
Server side biometrics
In principle stronger than the client side. Not because we would use different algorithms to assess the likeness of the two pictures when comparing the faces (or voice for that matter), in fact the technology behind may even be the same. It’s because it’s carried out in a controlled environment, without compromising the physical access to the brains of the operation (the comparison and decision is made on the server in a datacenter or cloud, not locally on the device). We’ll talk about it more later.
Client side biometrics
All our phones and security keys like Yubikey Bio carry out client side biometric authentication. It means that the decision whether the sample matches the original is made by the device itself. The mechanism must be strong and impenetrable (in principle) because it resides in the wild west of the user’s realm (not in a datacenter which would be a controlled environment). Let’s think about it in the language of 10 immutable laws of security. One of them says that ‘if a bad guy has unrestricted physical access to your computer, it’s not your computer anymore’. While we have engineered technology to keep our data safe in case this happens (stolen laptop or phone), what we’ve done is effectively making the potential hack exponentially more difficult – but not impossible – again in principle.
FIDO2/WebAuthN and Passkeys…
Can we really say that we’re doing biometrics when we use passkeys? I think the answer is somewhat tricky. They can be… but not all are. A passkey in itself is a possession factor (something you have), so no we cannot say a passkey is a form of biometric authentication. It’s just some cryptographic material, part of which (needed for end to end flow) was meant to never leave the user’s device when they were first designed. It was at the time its biggest security advantage. You needed to physically steal it. Things evolved since, but we’ll come back to it.
A passkey in itself cannot do much but if you use an authenticator it can consume the passkey to carry out the authentication process. Those authenticators come in two flavours – local (embedded) and roaming. Local authenticator’s example will be Macbook’s TouchID. You can only use it to consume the passkey on the laptop itself. A good example of a roaming authenticator would be a security key, like for example a variety of Yubikeys. You can connect it to any device compliant with the connector (USB or NFC) and carry out the authentication process.
But the passkeys carried a big issue from their beginning. What happens if I lose my authenticator and in consequence – the passkey? Well, the answer was simple, you lose the access. That in itself slowed down the adoption of this very strong authentication method and passwordless journeys. The cost of its management was too high and dealing with lost devices was expensive (more so from the process and access recovery perspective).
Apple and Google decided to solve this problem once and for all and introduced a custodial mechanism of managing passkeys. And we have NOT been given a choice*. From now on when you decide to enrol for a passkey using your mobile device (phone or tablet) and its built in authenticators like FaceID or TouchID, it’s going to be stored in your keychain, in iCloud or Google Cloud respectively. What does that mean from a practical standpoint? Let me give you two examples. Firstly, if you enrolled for a passkey for a given website on your phone, it is immediately available on all of your devices in your ecosystem, for example on your tablet – IF you are logged into the same cloud account (e.g. iCloud in your Apple ecosystem). Secondly, if you only had one device and lost it, all you need is a new phone or tablet and the login to your iCloud service. Neat, right? Yes from the usability standpoint, but creating a whole lot of implications on security and what’s worse – standards and compliance requirements. Additionally, the phone’s authenticators are now considered roaming, not local.
So, if you want a crypto material that never leaves the device, you are (practically) left with security keys* – roaming authenticators, like those manufactured by (but not limited to) Yubico corporation.
To complicate this even more, MFA (Multi Factor Authentication) principles experience what laws of physics experience near black holes. Authenticators themselves may be single factor or multi-factor but… they utilise the same channel. For example Yubikey NFC is a single factor authenticator – you plug it in, press the button and et voila, crypto material used for the passkey is unlocked. Yubikey Bio requires your fingerprint to unlock the secrets. So the secrets are ‘something you have’ but the fingerprint is ‘something you are’. Regulators can’t keep up and PSD2 SCA is still a little disconnected given the new technology being available (and actually maybe that’s a good thing after all, which you’ll understand why very shortly).
The chain is as strong as its weakest link
Let’s follow the logic. It’s the implementation of the authenticators that draws the line between being a biometrical authentication or not. Here’s the problem with Apple’s ecosystem. The MASTER KEY to your phone isn’t the passkey or FaceID/TouchID. Apple continued down the road of customer usability and when you ask the chicken and egg question, the most significant security element that gives you access to your phone is… the PIN. In fact if you reboot your phone (and in few other scenarios, too by the way), you are required to enter the PIN before you can start using FaceID.
Is displaying red light at a pedestrian crossing a super-secure control to avoid collisions? It isn’t, but it does significantly reduce accidents. It’s a policy that requires more controls to make it stronger and eliminate collisions completely. For example a copper on the other side of the road watching your every move. But even that doesn’t guarantee 100% safety. A physical barrier impossible to cross would. And it’s a very similar story with the passkeys on our phones.
Let’s see why using your phone with a roaming passkey is NOT a biometrical authentication after all. The reason is the compliance. Just because we used the face to unlock the crypto material for the passkey doesn’t make it compliant if there’s a strict requirement for biometrics. It’s like displaying the red light which someone (genuine or bad actor) may or may not obey.
Since the biometric sample used for enrolment is NOT tied to the passkey itself, I can potentially re-enrol my face – if I know the PIN for the phone. To make it even worse Apple allows for multi-appearances, in practice it means that both my wife and myself can unlock my iPhone. And that breaks the principle of biometrics – it should be a ONE to ONE relationship to make it ‘something’ YOU are. Singular. Have you noticed if your banking app asked you if you want to use FaceID? Did they ask additional question of ‘are you the only person’ that has the access to the phone? That tactic is nothing more than a mitigation technique, transferring the risk of non-compliance to you.
Apple isn’t the only one doing so. Yubikey Bio works based on the same principle. If you lose your finger (pardon the macabre) PIN is used for the recovery.
There are vendors offering smart cards with fingerprint readers with NO guardrails for recovery, meaning they become unusable if you cannot provide the right fingerprint to unlock.
It’s important to understand that the design of all of the above is a result of conscious decisions made by the vendors, which fit with their business models and strategies.
Are passkeys bad then?
That’s an easy answer, it’s a resounding NO. In fact – they’re very strong and fit for their purpose.
Passkeys come with a few other perks (non-replayable, resistant to Man In The Middle attacks, effectively making phishing technically impossible etc.) and are exponentially stronger than passwords. In fact, believe it or not – a single factor authenticator using passkeys can be much stronger than some traditional MFA pairings. If you are however regulated or have stricter requirements around biometrics, they may not be the right solution for you. Check part 2 of this blog to read about server side bio authentications.
* Things are slightly more complicated and I need to mention this. Our semantics fail us unfortunately. Although ‘Passkeys’ (as most recognise them by scanning a QR code) are considered roaming these days, if you use WebAuthN on a laptop or desktop’s browser, you still have the ability to drop a ‘local’ passkey which WILL NOT be synced to the cloud – because you are using a local authenticator. If you run the same journey on a mobile browser – you get no choice and you can only set a roaming passkey. In fact even if you try to enforce a platform passkey, the browser will not honour this request and you will continue to register a roaming passkey, because the authenticator involved is of roaming nature itself.