Pilot service for Yubikey two-factor authentication

December 13, 2014

A new project

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 11:33 am
Tags: ,

The test OpenSSH service described in previous posts which uses Yubikey two-factor authentication seems to work fine, has been running in a very small-scale way since about August 2014, and was in fact developed as part of the more general investigative precursor project Project 279 – Options for two-factor authentication.

However, as mentioned in an earlier post, in order to make our overall site configuration both sensible and consistent, we’d definitely want to integrate the use of Yubikeys into our Cosign-protected websites too. So, having satisfied ourselves that the use of Yubikeys seemed to be viable, we created the project which is the subject of this blog – namely Project 313: Pilot service for Yubikey two-factor authentication – in order to develop a more fully-fledged ‘test’ service.

The previous posts bring this blog more or less up-to-date with the state of the test two-factor OpenSSH service, but by now there has also now been progress with Cosign integration.

In the New Year, I’ll post more information about the new project and, in particular, progress with integrating Yubikey use into Cosign.

December 12, 2014

Towards two-factor Yubikey authentication with OpenSSH

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 5:21 pm
Tags: , ,

Our overall strategy for a test OpenSSH service using two-factor authentication via Yubikey is now clear:

  1. Integrate Yubico’s PAM module into the PAM stack used for our ssh service.
  2. Configure that PAM module to authenticate against the Yubicloud service.
  3. Organize our configuration so that only those users who are registered (somehow …) for Yubikey use are required to submit a Yubikey OTP.

Since we definitely don’t want to mandate Yubikey use for every user, how can we arrange this final (very necessary) requirement? It turns out that the (previously unknown to me) pam_succeed_if module can help. That allows an ‘if test’ which tests for group and/or netgroup membership to be arranged in the PAM stack. So, what we need to do is to instantiate a suitable group (or netgroup) which contains the UUNs of all those users registered for Yubikey use.

To keep things as simple as possible for testing, we’ve chosen to set that up for now as a group, called yubikeyusers. (We’ll almost certainly use a netgroup in any final live implementation.) The relevant lines of the resulting PAM configuration are as follows:

 
auth	[success=ignore ignore=ignore default=1]	/lib64/security/pam_succeed_if.so	debug user ingroup yubikeyusers 
auth	required	/lib64/security/pam_yubico.so	id=<secret> key=<secret> authfile=/etc/yubikey_mappings debug

Some notes about the parameters to the Yubico PAM module pam_yubico.so:

  1. We’ve got debugging turned on for this module so that we can get detailed output from the authentication process. For that to work as expected, it’s necessary to ‘touch’ the nominated log file in advance:
    touch /var/run/pam-debug.log
chmod go+w /var/run/pam-debug.log
  2. The <secret> strings are our private keys for use with the Yubicloud service. Such keys are freely available from Yubico.
  3. The file /etc/yubikey_mappings contains the mappings of Yubikey public ids to local UUNs. That is: it formally associates actual Yubikeys with actual users. (An individual user can be associated with more than one Yubikey, by the way.) In a final live system, we’d expect to integrate that same information into our LDAP directory: Yubico’s PAM module can read from that.

Yubikey authentication

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 5:04 pm
Tags: ,

The Yubikey authentication standard is proprietary – but it is completely open. So it would be perfectly possible for anybody to implement their own authenticator from the ground up.

However: why bother? Yubico makes a lot of source code available at its github site including:

  1. Source code for an authentication server.
  2. Source code for a PAM module which interfaces with the authentication server.

In addition, Yubico provides a free ‘cloud-based’ authentication service, ‘Yubicloud’.

So in fact experimenting with Yubikey authentication is easy: for a start, anyway, we can just use the ‘Yubicloud’ service.

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.

Some background

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

There is a bit of catching up to do here …

A while ago we collectively wondered whether we could or should be using ‘two-factor authentication’ when accessing our various services. Those questions spawned a precursor project called Project 279 – Options for two-factor authentication.

It turned out that ‘two-factor authentication’ covered a wide variety of very different ‘use cases’ for us – see the various cases in the initial ‘discussion paper.’ Ideally, we’d like to investigate all of those at some stage, but, since trying to do everything at once is never a good idea, we decided to pursue the particular question of how to implement two-factor authentication for external access to our principal access gateways, namely external-facing ssh servers and Cosign-protected websites.

So we then wondered how to do that. It turns out tha the ‘obvious’ answer is to use some kind of hardware and/or software device to generate some kind of ‘one-time password’, and then to integrate the use of that password into the ssh and Cosign authentication processes. Having looked around, we decided to try to use the Yubikey hardware device for this purpose. It’s not the only such device of course, and there are software alternatives – but the hope was (and is) that if we could get ssh and Cosign working with Yubikeys then that might provide us with a good solution. And, if it didn’t, that we could probably use the experience gained to integrate other similar devices or approaches. In summary: we have to start somewhere!

So that’s the brief background. The current project has the aim of producing a pilot two-factor authentication system for ssh and Cosign, all based on the use of Yubikeys.

Initial post

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 2:07 pm

I’ll be using this blog site to document thoughts and progress on the Informatics internal development project Project 313: Pilot service for Yubikey two-factor authentication.

Comments from any readers are invited, and would be welcomed.

Theme: Rubric.