So many discussions are everywhere about FIDO, so what is all that fuss about? Lets look into why FIDO is argued to be the next big thing in authentication.
Before getting into it, let me say thanks to all the support and help we have received from a vast array of security manufacturers. More on them and hardware security keys later.
Where to start
To understand where the idea for FIDO comes from, it is necessary to start at the beginning. The beginning in this case is authentication using passwords. So what is the problem with passwords? They have served us well for a long, long time but lets take a step back.
Passwords are what’s called a shared secret. A shared secret is known in the simplest form by the user and the system the user is attempting to authenticate with. Every time the user authenticates, the shared secret needs to be passed from the user to the system to authenticate. The challenge being, the shared secret needs to be transferred, allowing spying eyes to possibly steal it in transit. And even with encrypted connections preventing that, those passwords are not completely secure.
When systems get hacked, and the user and password database gets stolen or leaked, the shared secret is out and basically is not a secret any more. Even with passwords not being stored in plain text in the database, since usually only a hash is stored, it still poses a huge risk to have these hashes leaked. Way too often password databases have been stolen in the recent past. But what would be the solution?
Improve the authentication mechanism
The next logical step would be a way to authenticate without actually transferring the secret in the first place. This would eliminate the chance an attacker could steal the shared secret in transit, but still it does not solve the risk of the password being stolen in the password database of the system to authenticate at.
To address that, wouldn’t it be even better to authenticate without even storing the password on the system to authenticate? That would fix the transit risk as well as the problem of storing it on the authentication system.
How would such an authentication mechanism look like? A system where a user can authenticate without sharing a secret? Such a mechanism would send the proof of having the secret only. The proof would be sent in a way to verify it on the login system side without ever knowing the secret.
What about FIDO
The FIDO alliance set out with the goal to develop authentication standards less dependent on passwords. With the above thoughts in mind, the standards developed happen to have exactly those properties.
FIDO uses public-private key cryptography to solve the shortcomings of shared secrets. By using public-private key cryptography, the private key is kept by the user and is never transferred to the system to authenticate to. When FIDO is used, the system to authenticate to only needs the public key of the user which is, as the name implies, public information and is not required to be kept secret.
In the FIDO standards, the system to authenticate to is called the relaying-party and the component storing the private key and performing the cryptographic functions is called the authenticator.
While FIDO U2F (the first version of the FIDO suite) aims to replace the second factor, the aim of FIDO2 is to replace password authentication as a whole with FIDO authentication. Time will tell if this goal will be reached with FIDO. No mather if FIDO is used as a second factor or to replace the password authentication, the procedures described are similar enough to make no distinction for now.
Simplified, when setting up FIDO authentication to authenticate, the authenticator is registered to the relying-party. This is done by creating a new key pair, a credential, in the authenticator for this specific repaying-party. Having a separate credential created for each system to authenticate to also eliminates the possibility for reuse of credentials that causes a lot of issues in today’s password leaks. Even though re-using public-private key pairs would be less bad than reusing passwords, the protocol ensures that every relaying-party gets its own credential as a precaution.
When authenticating, the relaying-party is issuing a challenge which is passed on to the authenticator. The authenticator uses the credential for this relaying-party (its private key) to sign the challenge. With the signature sent back to the relaying-party, it is time to verify it. On the relaying-party, the public key stored as part of the FIDO details can be used to verify the signature. With the cryptographic proof that only the known private key of the user/authenticator could have created the signature, the user is authenticated.
As described, the credential is created for the relaying-party which means the credential is bound to the relaying-party. For authentication to websites, the relaying-party is the domain name, or FQDN to be precise, of the website. With this in mind, FIDO authentication can help to combat phishing attacks. As a lookalike domain name and in turn a lookalike relaying-party will not trick the FIDO device. The FIDO device will not find any matching credential as the credential is registered to the proper relaying-party.
Hardware security keys
Hardware security keys offer a secure place to store the secret keys required to authenticate. They are easy to use thanks to the multiple protocols available to communicate. The physical connection via USB is not the only way to connect the hardware security key, the FIDO standard also specifies NFC, which is used by a lot of the available security keys, as well as BLE (Bluetooth Low Energy).
Bluetooth Low Energy
BLE is a great way to connect to a mobile device. No need to physically connect or touch the smartphone. With that said, BLE also comes with a few drawbacks. First, a BLE enabled device requires a power source. Most of the time a battery, and batteries need to be charged. If the battery is empty, you can’t use BLE until it is charged up again. As bad as this sounds, most if not all of the BLE devices we have seen also support NFC and USB. That means with an empty battery, you only lose the convenience of the BLE connection but still can use them via USB or NFC.
Probably the biggest limitation of BLE, at the time of this writing, is Apple. Even though Apple seems to support BLE on a hardware level on their mobile devices, it seems BLE devices can not be discovered and paired without third party apps. Also, it seems that even when paired with a third party app, hardware security keys can not be used via BLE. Even the “About Security Keys for Apple ID” page only refers to USB and NFC. It is a shame especially when considering how flawlessly BLE security keys work on Android devices.
Short summary
FIDO changed the concept of having shared secrets that are hard to keep secret to a public-private key system where the private key (the actual secret) is never transferred or shared. This change in authentication increases the security of the authentication mechanism but comes with a few inconveniences as well.
While the FIDO standard increases the security, there is the additional complexity of storing the secret key in a safe place. Those secret keys are too complex to remember. Hardware security keys are one way to store these cryptographic credentials to authenticate. As easy as they are to use, they need to be with the user anytime the user wants to authenticate.
Manufacturer support
At this point I want to say thank you for all the support from all the security key manufacturers from around the globe. Thank you for not only providing your devices for free testing but also your know how and patience with all our questions. And all without asking for any special treatment or talking points.
Without any particular order, here are the security key manufacturers that were supporting us. Make sure to check their websites if you are looking for a security key.
- Crayonic
- Cryptnox
- Ensurity
- Feitian
- GoTrust
- Identiv
- Neowave
- Nitrokey
- OnlyKey
- SoloKeys
- Token2
- Trezor
- Yubico
Read more of my posts on my blog at https://blog.tinned-software.net/.
