Re: [OATH-Toolkit-help] pam_oath and multiple tokens for a user

[Simon Josefsson]

Fredrik Lindgren <address@hidden> writes:

> On May 31, 2012, at 10:46 PM, Tim Eggleston wrote:
>
>> Hi Simon,
>> 
>>> Having the same secret in several devices is usually not a good idea --
>>> instead, how about a scheme to have multiple lines in users.oath for the
>>> same user but with different OATH secrets? Then each OTP could be
>>> tested against all lines for a user, to find which device is relevant,
>>> and then that line could be updated.
>> 
>> Perfect! This is exactly what I was hoping for. As well as enabling
>> flexibility in cases such as mine (where I use a couple of Yubikeys
>> day-to-day), it would also allow us to be a bit stronger with our
>> pam config: we could configure a backup token which was stored
>> somewhere safe & secure, and then we could require the OTP to
>> authenticate instead of making it "sufficient", knowing that even if
>> we lost our primary token we could always fall back to the backup.
>> 
>
> This is something I too would find very useful. Simon, have you had
> time to decide if it's something you plan to do?

It seemed like a good idea to me, but I haven't started looking at
implementating it.  This week is pretty busy, so if someone else wants
to start, please do.  Look at liboath/usersfile.c as the starting
pointer.  I'm not sure how it should be implemented -- you COULD do it
like this:

  1) have an output integer variable from parse_usersfile that indicate
  the position in the file that was used (nth occurances of that
  username)

  2) let update_usersfile take that parameter, and have it skip lines
  until it reaches the nth line of the right user

however this leads to a race condition if someone changes the order of
lines in the file between these two calls.

Alternatively, the file could be locked during the entire
parsing+validation+updating step.  I'm considering using a PKCS#11
backend for the HMAC-SHA1 step, and then such a long lock could be
problematic.

However, all this assumes the usersfile is the right solution for user
management in the long term, which it clearly isn't.  So maybe both
approaches above would be fine.  Eventually the user management stuff
should be moved to LDAP or other PAM modules.

/Simon