Options for two-factor authentication

This is the final report for Project 279 - Options for two-factor authentication.

Contents

1. Introduction

The aim of this project was to investigate the options for two-factor authentication.

'Two-factor authentication' might mean different things in different circumstances - and note that the phrase 'secondary authentication' (which also featured in the initial motivations for this project) might mean something different again. See this project's homepage for an initial discussion paper which tries to clarify what our own 'use cases' might be, and what are the particular problems which we might want to address.

2. Outcome of the project

The above-mentioned discussion paper elicited comments from some COs, and it should stand on its own as a record of the various and distinct things which we might want to address. There remains much scope for both thinking and work on aspects like 'secondary authentication' in the management of DICE: in that respect, those responsible for services like rfe for example should consider what types of authentication ought to be required in future.

However, in order to avoid being overwhelmed with possibilities, the decision was taken in this project to concentrate on the use case requested by a member of staff, namely 'More secure remote access' (or 'Case 3' in the discussion paper.)

A brief survey showed that a reasonable (but not necessarily 'best') way to proceed would be by the use of hardware (and/or software) devices capable of producing one-time passwords, and investigation showed that 'Yubikeys' were an obvious contender. After some difficulty, two test Yubikeys were obtained, and these were successfully used to prototype two-factor authentication for an ssh service. Rather than continue that particular effort under this general project, it was decided to spin off a specific project to pilot Yubikey two-factor authentication for use in both ssh and Cosign use.

We should note that 'other one-time password devices are available', and that indeed the Yubikey itself can be used in a variety of different modes. There appears to be lots of activity in this general area, and the hope is that knowledge gained from experimentation with Yubikeys should be directly transferable to other approaches. (In this respect, we specifically refer to OATH-HOTP/TOTP standards and the Google Authenticator. Note that the Yubikey can support OATH-HOTP as well as its native proprietary mechanism, so there is a promise of a local Informatics two-factor authentication service based on OATH-HOTP which allows second factor authentication using either a Yubikey hardware device, or a soft token produced by a mobile phone app.)

3. Future work

We propose to wind up this project: it is expected that the related future work will be performed and documented under the auspices of the spun-off project: Pilot service for Yubikey two-factor authentication. The current state (at Dec 4 2014) of that effort is that Yubikey use has been integrated into Cosign in prototype form. Work remains to consolidate the effort, and to provide a viable pilot service. Many of the issues being encountered are specific to the design and implementation of Cosign itself, rather than to the Yubikeys (or similar devices) per se.

4. Effort

The total effort for this work is approximately 17 days. That includes an attempt at a synthesis of requirements, prototyping of an ssh service using two-factor authentication via Yubikeys, and documentation.

5. Lessons learned

This project fell a long way short of a full 'investigation of the options for two-factor authentication.' However, we were starting off from a position of no experience at all, and it seemed important to actually try something (anything!) concrete in order to gain a toehold on the subject. When and if some practical experience has been gained with two-factor authentication, and when we have more focused ideas of our important 'use cases', it might be useful to return to the idea of surveying the field, and attempting to find the 'best' (or, at least, 'better') options for us.

In any such survey or work, it will be important to have a very good idea of the exact problems we are trying to address.

A general comment is that the more-focused a project can be from the beginning, the better. But that is difficult in investigative/survey work.

-- IanDurkacz - 11 Dec 2014

Topic revision: r2 - 12 Dec 2014 - 11:42:36 - IanDurkacz
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies