Before this post on YubiKeys, we recently published a couple blog posts over the last few months on passwordless authentication and emphasized the importance of multi-factor authentication in our National Cybersecurity Awareness Month post.

We’re always keeping our ear to the ground on advances in these areas, and with a recent announcement at Microsoft Ignite, Yubico, the leading provider of authentication and encryption hardware, and YubiKeys, the authentication devices they manufacture, have been in the news. We have also been seeing a lot of conversations pop-up on LinkedIn regarding YubiKeys and their uses in both the passwordless authentication and multi-factor authentication spaces.

In an effort to provide some clarity on these devices, we talked to our own James Grow, Director of our DevOps and Security Automation practices at Fishtech, and asked him to define what YubiKeys are, and why he uses them. Below you’ll find his quick write-up, and a video of James demoing how he uses his YubiKey.

 

YubiKeys Aren’t A New Hardware Token

YubiKeys aren’t a hardware token. They’re a radical shift in the fundamentals of how we do trust, authentication, and identity.

YubiKeys work with new, standard/open APIs such as WebAuthn. They implement strict controls and checks to provide better guarantees, such as trust. They also enable passwordless multi-factor authentication that, at least so far, completely mitigates phishing attacks. It seems to have eliminated an entire class of security threat.

How often do we see an entire threat vector eliminated? Once or twice in a lifetime?

Here’s a little more detail on how it works, and I encourage anyone curious to check out WebAuthn and FIDO2.

Registration

  1. When a user first logs onto a service – they provide their username, and it’s passed to the relying party (service/app we are signing on to use). No password is entered or exchanged.
  2. The server sends back a challenge key for the user for one-time registration and provides its relying party info – the client verifies this for authenticity, then checks against it any time the user connects to this app again.
  3. The authenticator (YubiKey) is triggered to perform user verification and consent (pressing the button, entering pin, biometrics).
  4. Authenticator – YubiKey – generates and exchanges a public-private key-pair that is explicitly associated with this app via a credential ID. The credential ID and public key are combined to create an “attestation object,” and provided to the relying party/service. The attestation object is a mechanism to do verification checks of the authenticator’s integrity.

No password, PIN, or anything else has been exchanged or can be phished/spoofed.

  1. Finally, the server/relying party verifies the challenge-response and signatures are good and registers the client/authenticator.

Authentication

  1. User signs on by providing their username to the server (relying party).
  2. Server provides a challenge, and it’s relying party info
  3. The client verifies the relying party ID against the origin. Then the YubiKey is given the domain name the challenge is associated with and requests consent from the user. If the domain doesn’t match the data saved during registration, the server/relying party is considered a risk and not trusted.

That last point is a very crucial distinction and why YubiKey/WebAuthn hard counter phishing attacks. The YubiKey has the server/relying party’s domain and info from registration stored directly. If an attacker tries to trick the user into entering credentials into a spoofed site, the authenticator fails the verification check, helping to eliminate the weakest-link – untrained or careless users, or even experienced users duped by a sophisticated counterfeit.

  1. The authenticator/YubiKey creates and sends a signed assertion and authenticator data partially derived from the key exchange during registration.
  2. Client/browser forwards auth data from YubiKey/authenticator and includes the PublicKey associated with the service/relying party.
  3. The server/ relying party validates the challenge and checks the keys/signatures against its records from registration. If all checks succeed, the user is authenticated and is verified/trusted. And we can be confident of this. No one entered a password or struggled to get their phone out to authorize a push.

So, the service and the user mutually can be confident of their authenticity/integrity, and that the interactions are intentional via multi-factor authentication.

Hopefully, this has helped bring some awareness and understanding, and hopefully, excitement about how game-changing this is!

If you would like to talk to one of our experts more on security keys, passwordless authentication, and multi-factor authentication, fill out the form below.