Re: [Otpasswd-talk] Re: Otpasswd tasks

[Hannes Beinert]

On Sun, Dec 27, 2009 at 15:27, Tomasz bla Fortuna <address@hidden> wrote:
>
> Thanks for this proposition. There're some things which can be done
> independently of the code, sure:
>
> 1) Testing. Needed ;-) But it would be better to wait until this
> global db works and I implement parts of policy... I'll create some tag
> briefly.
>
> And normal testing (using it) is fine, and you can thing about some
> testcases which can also be used (code coverage might help). e.g. OOB is
> not tested at all currently...

I haven't carefully looked at the test cases you've written so far,
but I can certainly take a look.  Perhaps some of the tests I wrote
for Tom Fors' project might apply somehow.

> 2) Portability/Packaging. I'd like to run it on Linux, BSD and Mac
> minimally. Should work on Solaris also without big pain. This might
> require some header changes, maybe some #ifs and cmake changes.
>
> My fast check on FreeBSD made me change PAM-headers-include a bit, so
> it'd be cool if you can try to compile it on Mac and see if headers are
> ok, and if cmake does it's job. If it compiles then just wait for the
> next tagged version and it can be packaged. ;-)

I don't have access to Solaris, however I can certainly help with some
Linux distros and OSX.  Cmake is available through Fink and MacPorts,
so that shouldn't be a problem.

It depends on what type of package you want to generate for OSX.
Without requiring cmake, then an Autotools build system would have to
be added, AFAIK.  I'd be happy to do this.  If requiring cmake is okay
with you, then I can't imagine much needs to be done apart from making
sure it works (:-).

> I've had one mail from guy who was compiling it on debian with some
> cmake problems; I guess it can be enhanced somehow. I've got no idea how
> to make .deb packages and how difficult it is to place project inside
> experimental debian branch. It would be cool to do so as it'd make the
> project better reviewed.

I've never generated a Debian package, but I've always wanted to
learn.  I can certainly start reading about it.  And I agree, getting
this project into Debian unstable would be an excellent goal.

> 3) Documentation. Hm. It would be cool to create a manual page, at
> least one single for utility out of --help screen with some initial
> paragraphs from README. I guess this can be done easily by taking
> something ready and just remaking it. Checking if README is
> gramatically correct would be cool too. ;-)

I can do this, too.  As you say, I think a quick-and-dirty man page
would be good to have, then ultimately I'd love to see a more thorough
set of documentation, as we discussed in a previous email.  I would
really love to use parts of Gibson's PPP webpages, but we really need
his permission before using the content.

> BTW.
> I wonder about default configuration. It could look like this:
> otpasswd user created by package.
> /etc/otpasswd owned by otpasswd user.
> /etc/otpasswd/otpasswd.conf is a config, owned by otpasswd user.
> /etc/otpasswd/otshadow  - empty, otpasswd-owned, rw- --- ---
> /etc/pam.d/otpasswd-login owned by root
> /usr/bin/otpasswd is not SUID, but is owned by otpasswd.
> State is kept in user homes.
>
> Then if user wants to use global DB he can easily make binary SUID and
> change config to use DB=global...
>
> OTOH if he changes DB=ldap then he must change (or otpasswd can do it
> automatically) config to be rw- --- --- as it will hold password...
>
> OR
> Make otpasswd SUID by default, then config can by default
> read-only-by-owner. As it reads DB=user it can drop this permissions
> fast. Switching to other db is faster (And safer) then.
>
> Just think about it in free time.

As I wrote Luke, I really am not somebody who believes that
configurations should, by default, be "system-level".  I completely
agree that it is traditional under *nix systems to put configurations
in the user space.  However, I do believe that this type of
security-related facility is an exception.  The fact that the user can
negatively impact the usefulness of OTP by messing with the state
files really bothers me.  This is why I would choose the second option
-- this would make it harder to make an installation choice which can
lead to security problems.

Now, if you were to include the use of a MAC or MIC/hash of critical
user state file material, then I think I would change my mind.  The
MAC would have the advantage that it could be kept in the user's state
file, and that otpasswd would only have to know a single system-wide
secret to verify the integrity of a user's state file.  The
disadvantage is that it would require the handling of a secret key,
which would be painful, and I'm not sure the effort would be
worthwhile.  It would also raise the additional problem of a
key-change.  The hash, OTOH, would require a global database of user's
hash values, which just introduces a global database of another type.

The bottom line is that IMHO the principle reason a sysadmin would
install an OTP package is to increase system security as a whole.  And
the only way to do that, while ensuring that no user can compromise
this system-wide security increment is to ensure that the state files
are *never* modified in a stupid fashion -- and to me, that just
implies that some system-level bookkeeping must exist.  If there is
another way, and if I'm just not thinking of it, then I would be happy
to be wrong.

> Another problem: otpasswd with db=ldap can either use master password
> for everything or ask user to supply password for his part of LDAP
> database (then no suid is again required; but PAM will need password
> stored separately from config in only-root-readable file).

Huh.  I see what you mean.  I really don't like "master passwords", in
general.  In this case, though, I don't see that the security
requirements of storing and protecting the master password are any
different than a file of individual user passwords.  I can't think of
any advantage to individual user passwords -- can you?  A compromise
of the master password is just as bad as a compromise of the user
password file, so the worst case scenario is the same, it seems to me.

It would be very cool if one could use the user's unencrypted login
password to protect the LDAP key material, but that's not really
feasible (nor should it be).  IIRC, one suggestion that was made on
the newsgroup, several years ago, was to use the passcode itself as
key material to decrypt the sequence key.  That's is a very clever
idea, but it has the disadvantage that it prevents one from skipping
any passcodes.  I wonder if some variation of that idea would work.
For example, suppose the sequence key was stored in the LDAP DB twice,
once encrypted by the next passcode, and once by the static password.
If the user typed in the next passcode, then otpasswd could decrypt
the sequence key, validate it, generate the next passcode, and
re-encrypt the sequence key with that (next) passcode.  If the user
wanted to skip passcodes, s/he would have to enter the static password
anyway, which again would make the sequence key available.  The only
problem that I see with this scheme is that it would have an effect on
concurrency.  If multiple login sessions were concurrent...  that
would be a problem.

The really cool thing about this type of approach would be that
otpasswd would never have to manage any unencrypted secrets on disk.
The keys would be provided just as they are needed.  But, I don't know
if this could be made useful.

Hannes.