Re: [Otpasswd-talk] Re: Otpasswd tasks

[Tomasz bla Fortuna]

Dnia Sun, 27 Dec 2009 17:13:10 -0600
Hannes Beinert <address@hidden> napisał(a):

> 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.
Some are in CMakeLists.txt, some (internal --check) in testcases.c, 
PAM is in tests/pam_test.c (runned by do_pam_tests.sh, but this touches
system (make install) and /etc/pam.d and user state)

> 
> > 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'm not very bound to this cmake. I just had to choose: autotools or
cmake, and cmake was easier. ;-)

When moving to autotools we'd have to move there testcases from
CMakeLists.txt. Cmake can compile this project ok, so removing it will
be nice only because of removing additional dependency. Autotools are
much more standard and for example FreeBSD might be much more happy
with it. 

If I'd manage to drop GMP dependency completely we could go for BSD
license and try to standardise it in fbsd, hah. Ok, maybe not yet...

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

It works almost exactly as passwd tools which keep user data
in /etc/passwd while allowing user to modify it while conforming to
system-wide policy. That's the most important argument for-global state
file.

In general /etc/shadow also could be splitted into user homes, just it
would be impossible to ensure password length.


We've got at least 2 kinds of config here.
1) User conf (like show/don't show flag, contact, label, maybe
something more in future, use otp/don't use otp).

2) Definetely system-wide: How PAM module is supposed to work. At first
these were passed as module parameters, now there're in system-wide
config in /etc for cleanness. For example should we use OTP, enforce OTP
usage, should we use OOB (and how) etc.

2b) Policy limitting what user can do with his part of config.

> 
> 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. 
Yes, that's kind of difficult and non-standard approach. Theoretically
possible, but utility still has to be SUID to read the secret and I
guess it's not worth doing. If we are SUID we can keep data in global
state and we're set. Just to write it correctly. ;-)


> key-change.  The hash, OTOH, would require a global database of user's
> hash values, which just introduces a global database of another type.
One secret would even be enough to check that state is correct (but
user could revert to previous known state with previous, correct
hash... Really, this approach is weird. ;-)

> 
> 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.
Some thing you've said later is possible - LDAP database with user
having his own password for specific part of LDAP. When user calls
otpasswd he is asked for HIS pass for HIS part of db.

OTOH pam module has "master" key to access whole DB. No SUID required
in this configuration, but policy enforcement is difficult.

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

I'll try to make it cleaner: some kind of master password must be
always available so the PAM can access DB without asking anyone for
password. (If I understand it correctly).

But this master password can be used also for normal users, with SUID
utility which reads it, connects to LDAP and then enforces that user
can change only his part itself OR user might insert his password to
non-suid utility to connect only to his part (no policy here).


> 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.
Idea nice, although I'm not sure what it's supposed to fix (I'll think
tomorrow, or todays' morning). Concurrent logins are always problem.
and yeah, this could make it worse.

> 
> 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.
Also passcodes are short; 4 bytes of 64 possibilities by default. 16
mln of possibilities is enough for OTP but not enough if offline
brute-force attack is possible on key. So I'm not sure if it's secure
at all. (might be if we do not know whether decrypted key is ok, then
instead of 1 key we've got 16mln of theoretically correct keys... uhm).

> 
> Hannes.

Cheers, 

-- 
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl
pgp: 0x90746E79 @ pgp.mit.edu
www: http://bla.thera.be

signature.asc
Description: PGP signature