[OATH-Toolkit-help] Storage of credentials

[Max Thoursie]

Hello,

I had a breif discussion with Simon regarding how to store user
credentials (alternatives to the /etc/users.oath file) before he
pointed me to this mail-list. Let's continue the discussion here!

On Thu, Mar 17, 2011 at 7:26 PM, Simon Josefsson <address@hidden> wrote:
>>> Generally, I really like to move away from the usersfile and use LDAP or
>>> something else instead.  Re-writing and file locking doesn't scale...
>>
>> I see your point. LDAP or similar seems a bit tough for a requirement.
>> I had a look at barada before (http://barada.sourceforge.net/) and
>> they have a directory per user and one file for the key and another
>> file for the counter. How about that aproach? Doesn't scale to an
>> enourmous amount of users, but atleast avoids the file locking issues.
>>
>> Rewriting the input file does feels scary. At least a separation of
>> input values and updated values would be nice.
>
> Yep -- the barada scheme seems fine, and Google Authenticator has its
> own format too see:
>
> https://code.google.com/p/google-authenticator/source/browse/libpam/pam_google_authenticator.c
>
> I can't find any documentation on the format, but it stores information
> in ~/.google_authenticator.  I couldn't find a documentation of barada's
> file format either.
>
> Maybe we can design something which is a superset of these features?

I like the idea of storing the file in home directories like google
authenticator does, but I see one problem with it. If an intruder gets
access to that file, for instance through a unwatched terminal
session, she will get all information needed to create new tokens.

Simply using two files in /etc/, one for ids and another one for
keeping state, would perhaps be a good compromise for small scale
installations?

> LDAP should be optional, for those that follow the LDAP religion.

That would of course be nice. But providing a good solution for use
without LDAP is more important IMHO.