[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
/etc/oath/state-hotpe8-root.txt
/etc/oath/state-hotpt60-simon.txt
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
~/.oath/secrets.txt
~/.oath/state-hotp60-simon.txt
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:
/etc/oath/config.txt
/etc/oath/config-simon.txt
alternatively
~/.oath/config.txt
~/.oath/config-simon.txt
the files could contain content like this:
# Disallow re-use -- make sure a valid TOTP can only be used once.
disallow-reuse
# 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.
/Simon
Re: [OATH-Toolkit-help] Storage of credentials, Jean-Michel Pouré - GOOZE, 2011/03/18