[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[OATH-Toolkit-help] Re: Storage of credentials

From: Simon Josefsson
Subject: [OATH-Toolkit-help] Re: Storage of credentials
Date: Fri, 18 Mar 2011 12:00:09 +0100
User-agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux)

Max Thoursie <address@hidden> writes:

> 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.

Good point.

However sometimes you can't use /etc because the PAM module will not
have root access, e.g. when used through some webapp for example.

To support all usages, I think we need to support two variants:

1) Have a "global" configuration file, for /etc usage.

2) Have a "per-user" configuration file, for /home/foo usage.

Hopefully we can use the same file format for both variants?  Then the
choice becomes purely a configuration item.  For example if someone
wants to put secrets and state in /etc they can say:

auth requisite pam_oath.so state=/etc/oath window=20

and if they want the option 2) variant where the information is in
people's home folder they can configure it like this:

auth requisite pam_oath.so state=~/.oath window=20

Where the PAM module will replace a leading ~ in the filename with the
users home directory?

> 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?

Yes.  What seems to be recorded are for a /etc/oath/secrets.txt file
which contains 'username\talgo\tsecret' for example:

root    HOTP/E/8 1323334353637383930313233343536373839303
jas     TOTP/T60 3132333435363738393031323334353637383930


File content is algorithm-specific and for HOTP/TOTP it contains
'counter\tlast_otp\ttime' like this:

78      617363  2009-06-04T21:17:03L

If this is put in the users home directory the files would be


Note there is no passwords here -- I'm not sure we want to store
passwords, and if we do it should be hashed/salted/iterated with PBKDF#2
or something similar.  Storing plaintext passwords is just broken.
Maybe we can use PAM to verify the passwords?  That would be more
flexible, and people can put the password one-factor in LDAP, SQL,
/etc/passwd or whatever.

Hm.  We could also support configuration files like this:




the files could contain content like this:

# Disallow re-use -- make sure a valid TOTP can only be used once.
# Window size for how many OTPs after/before the expected one we'll accept.
window-size 42

That moves away some things from the PAM configuration.

Phew.  What are your thoughts?  Is this too complex?

>> 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.

Once we get the file formats above defined, writing a LDAP schema for
the same information and writing the code to retrieve/store the data
over LDAP will be relatively easy.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]