oath-toolkit-help
[Top][All Lists]
Advanced

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

Re: [OATH-Toolkit-help] oath.users: encrypted passwords and management t


From: Simon Josefsson
Subject: Re: [OATH-Toolkit-help] oath.users: encrypted passwords and management tool
Date: Tue, 19 May 2015 12:16:55 +0200
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux)

Paride Legovini <address@hidden> writes:

> Dear oath users,
>
> I'm trying to find a way to set up a secure OTP authentication mechanism
> for a multi-user server[1] and at the moment libpam-oath seems the best
> solution. Still there are two thing that I'm missing and I'd like to ask
> you if you have any workaround to suggest me or if they are somehow
> planned features.

Hello.  Sorry for slow response!

> 1. When using libpam-oath as a two-factor authenticator (fixed prefix +
> numeric token), the prefix is stored in the user file in plain text.
> This means that if the user file is stolen, the intruder will have all
> the information needed to generate new valid password. Why not storing
> the prefix encrypted, as it is normally done in /etc/shadow? This should
> be quite easy to implement, and I don't see why it shouldn't be done.

Passwords in /etc/shadow are hashed, not encrypted.  The HMAC key is
needed in its raw form, but it could be stored encrypted.  Ideas on how
to implement this are welcome.  It is possible, but I don't think it is
simple.  For the password, I agree it is a bad idea to have it in the
users file.

> Please not that I don't want to use the users' standard unix
> (/etc/shadow) password as a prefix. This could be easily implemented
> with pam_unix and try_first_pass, but I don't want the users' password
> to leak in case the keystrokes are logged, shoulder surfing or similar
> attacks.
>
> (Possible workaround: libpam-oath + libpam-pwdfile + try_first_pass. Not
> very clean, requires another pam module, another file to manage and keep
> secure, a dedicated management tool... Other solutions are welcome.)

Indeed, ideas on how to solve this would be good.

> 2. In some situations it would be nice to let users set up their
> password precix and OTP secret. What would be needed is a tool like
> /usr/bin/passwd that managed the libpam-oath users file, letting users
> to change their relevant data after authentication. I couldn't find such
> a tool. Is somebody working on it?

Not to my knowledge.  It would indeed be a usable tool.  The
alternative, of course, is to not perform the OATH stuff locally but on
a remote server, and setup RADIUS or something else and use a pam_radius
or whatever.

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

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