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

[Max Thoursie]

On Fri, Mar 18, 2011 at 12:00 PM, Simon Josefsson <address@hidden> wrote:
> Max Thoursie <address@hidden> writes:
>> 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.

Ah, right. Didn't think of non-pam usage.

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

It's only the secrets file which is sensitive. How about always
storing the state file in ~ ? That should avoid most file locking
issues.

The secrets file could be read from /etc/ (configurable) first and
then ~ , like the configuration for many programs works.

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

Seems good.

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

For the pam module, it would be nicest to set up two factor
authentication using pam. It seems, however, that is problematic with
openssh.

The passwords should definitely be hashed. (This is currently what
stops me from using the pam module right now.)

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

Can't we append options on the row in the secrets file, like

root    HOTP/E/8 1323334353637383930313233343536373839303
dissallow-reuse,window-size=42

(number of digits and time interval are already specified in the first
field, isn't it?)

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

I think it will be possible to get this all in without adding complexity.

/max