Pilot service for Yubikey two-factor authentication

December 12, 2014

What is a Yubikey, and how does it work?

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 3:56 pm
Tags:

A Yubikey is a small (about 3cm x 1cm x 2mm) passive USB device. When plugged into the USB port of any PC, it presents itself as a standard USB HID keyboard and, when the capacitive ‘button’ on the Yubikey is pressed, the device emits a character string which implements a one-time password (OTP).

Ignoring, for now, the details of the contents of the string, the point is that, if the string can be correctly handled as a OTP by the receiving server, the entire system is platform independent (more-or-less every PC or laptop has a USB port), and very easy to use.

Ok – so what does the ‘string’ look like? In fact, the Yubikey can operate in two different modes: either the standard proprietary ‘Yubico OTP’ mode, or ‘OATH-HOTP’ mode. (Aside: note, not ‘OATH-TOTP’: the Yubikey is unpowered, and so doesn’t have a on-board clock.) We’re currently using and testing the standard mode, though it might be that later on we move to OATH-HOTP for reasons of server-side compatability with software OTP producers.

In standard mode, then, and using its default settings, the Yubikey produces a 44 character text string in which the first 12 characters are a public id string, and the final 32 characters are an AES-encrypted OTP. Here (taken from the Yubikey manual) is an example of the output when a Yubikey is pressed three times in succession:

fifjgjgkhchbirdrfdnlnghhfgrtnnlgedjlftrbdeut
fifjgjgkhchbgefdkbbditfjrlniggevfhenublfnrev
fifjgjgkhchblechfkfhiiuunbtnvgihdfiktncvlhck
<-12 chars-><---------- 32 chars ---------->

You can see that the public id of the Yubikey here is fifjgjgkhchb.

What’s the content of the encrypted OTP? In essence, it’s nothing more than a monotonically-increasing integer. Authentication works as follows:

  1. Each Yubikey has a unique (symmetric) AES key.
  2. All such keys are shared between the Yubikeys, and the authentication server.
  3. On the authentication server, the AES keys are mapped to the public ids of the Yubikeys.
  4. On receipt of an OTP, the authentication server selects the appropriate AES key, decrypts the payload and, if it finds that the integer contained in the payload is larger than any previously presented by the Yubikey, authentication succeeds.

5 Comments »

  1. So when each time the dongle gives a “key” it is unique, and the server will only allow a new code to authenticate each time? It looks vulnerable to man-in-the-middle attacks.

    Comment by riddick — August 30, 2018 @ 7:51 pm | Reply

  2. So can your yubikey eventually ‘run out’ of codes, or would this take millions of years?

    Comment by Thomas — July 22, 2019 @ 5:39 pm | Reply

    • This question is discussed in Section 6 of the Yubikey manual, the fields of interest being the ‘Usage counter’ and the ‘Session usage counter.’

      The conclusion reached there is that, for “a Yubikey being used five times a day, 365 days per year, it will take 18 years for the [Usage] counter to get stuck.”

      So, for ‘normal’ usage patterns, the problem of ‘running out of’ codes probably won’t be a concern in practice. However, this certainly does depend on the intended usage – as the manual goes on to say: “Note that this finite nature of the counter makes Yubico OTP mode less practical to use in challenge-response settings where the interaction occurs very often. Consider HMAC-SHA1 mode instead for such settings.”

      Comment by idurkacz — August 14, 2019 @ 8:22 pm | Reply

  3. I think hardware tokens would be more popular if it wasn’t for the cost factor when rolling out to a large number of employees. That said the self-contained nature of hardware tokens is still a major advantage.

    Comment by Jeffery Birks — September 13, 2019 @ 11:08 am | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Your email address will not be published. Required fields are marked *

Theme: Rubric.