1. Two-factor authentication
Ian Durkacz
Development Meeting, 3rd December 2014

2. Review
Want two-factor authentication – and propose to do so using Yubikeys.
Reminder: what is a Yubikey, and how does it work?
We have a working implementation of two-factor authentication for ssh using Yubikey.
Idea now is to get similar authentication working for Cosign-protected websites.

3. Cosign Cosign documentation is scattered ...
Local cosign mods are also not very well-documented ...
It turns out that, since v2, Cosign has had (some) support for multi-factor authentication.

4. Cosign 'factors' (1) Cosign “factor” = “authentication type”
“factor” is an overloaded term which means:
an arbitrary string which is returned by an external authenticator on success.
the external authenticator itself.
But there are also “Legacy factors”: e.g. if Kerberos is used to authenticate the account, the “factor” is set to the Kerberos realm used.
Enforced per client by apache filter directive: CosignRequireFactor
Can have 'and' and 'or' combinations.
In our case, this is typically null – but sometimes we declare
CosignRequireFactor INF.ED.AC.UK
in order to exclude iFriend users.
Note: a null CosignRequireFactor means that authentication against any available factor is deemed sufficient. We need to be careful ...
Relevant doc: “Cosign Multi-Factor Specification, 20 March 2006, Draft 6”

5. Cosign 'factors' (2)
External authenticator(s) declared in /etc/cosign.conf:
factor <pathname> [-2] <form- field1> <formfield2> …
Will be invoked if (and only if) all listed form-fields contain posted data.
If authentication is successful:
writes factor name on stdout
exits with 0
Otherwise:
writes an error message on stdout
exits with 1

6. Yubikey cosign factor
Could write this from scratch according to the protocol above ...
… however: we already have a Yubikey PAM module – and it turns out that a Universal Cosign PAM factoradaptor is available. So we can use that to get started.
Finally takes the form:
factor /usr/local/cosign/otp login passcode
where otp is symlinked to the Universal adaptor, and a new 'otp' PAM service using the Yubikey PAM has been declared.

7. Demo Uses: Cosign-supplied HTML templates
Yubikey in standard configuration, authenticating against Yubico 'cloud' service
Target service configured as:
CosignRequireFactor INF.ED.AC.UK otp

8. General Cosign observations
Our current Cosign HTML is a little ugly. We need to change it to allow the use of one time passwords; perhaps it ought to be completely reviewed? (IS'es EASE layout seems cleaner, for example. Do we want to include Javascript at all? Etc.)
Are we sure that we're handling iFriends correctly? Are we permitting them access to only what we want? How do we check and/or audit? The various 'Require's in the Apache config seem a little confusing ...

9. Specific two-factor questions (1)
The design of Cosign means that the OTP input field will be visible to all users (modulo some Javascript magic.) That's a bit messy: are we happy with it?
Whether or not the OTP field is relevant for any particular target website depends entirely on the configuration of that target.
So: what site can we / should we use for a COs 'test' site?

10. Specific two-factor questions (2)
Cosign does not (currently) allow configurable auth/auth options per user. So how do we handle an 'opt-in' two factor auth system?
How do we handle the specific use case(s) we have? What are they?
(Comment: Yubikeys probably wouldn't be affordable for a site-wide roll-out.)
One suggestion: we could 'wrap' our OTP factor with a test which returns 'success' if a user has not opted in. A hack – but should work …