Re: [Otpasswd-talk] Some questions

[Tomasz bla Fortuna]

Dnia Sun, 3 Jan 2010 18:35:30 -0600
Hannes Beinert <address@hidden> napisał(a):

> Hi!
> 
> In going over the documentation, and in playing with otpasswd a
> little, I made the following observations.  Please understand, they
> are just thoughts.  :-)
> 
> 1. I never really thought about it that much, but it turns out that
> projects tend to need a canonical "short name" (which we've
> discussed), and a one-sentence "tag line".  We should probably
> standardize the tag line, too.
> 
> You've been using:
>      One-time password manager and PAM module
> 
> And without thinking, originally, I used:
>      OTPasswd - One-Time Password Authentication System
> 
> I'm not really concerned about the headers in the code, since that is
> something only a developer would see.  However, I think it does make a
> difference for enduser-visible documentation.  My only argument for
> the latter choice is that it conveys the notion of a "system", without
> trying to break it down into the (accurate) technical components.  The
> enduser doesn't particularly care about what a PAM module is, for
> example, he just wants one-time passwords.  Any thoughts?  I'll use
> whatever you suggest in the various documents, and try to do so
> consistently.

System is really OK. I had this problem before and I guess I didn't
manage to stay consistent. Such title is used on savannah, in .ebuild
and in code. I guess we can agree on using 
      OTPasswd - One-Time Password Authentication System

It's ok.


> 
> 2.  When I first started playing with the utility, I decided to "play
> dumb" and just try things.  This method of doing things comes to me
> with disturbing ease.  The first thing I tried after compiling was
> 'otpasswd --help' and 'otpasswd --version', to which I received the
> following message:
> 
>      ERROR:   Unable to open config file! (No such file or directory)
> 
> At that time, the /etc/otpasswd directory didn't exist.  Personally, I
> think that commandline options which "don't do anything" but are
> merely intended to provide information, should probably work.  It's
> obvious, of course, why this happened.  However, couldn't you print
> some warning messages ("no otpasswd directory", "otpasswd.conf
> missing") and set a "configuration not read" flag.  Then, go about
> option handling, but the moment you actually go beyond the innocent
> options, *then* you bomb out?
> 
> Also, when the error is given, it would also be helpful to alert the
> user (tersely) as to what needs to be done.  Something like, "otpasswd
> not properly configured, consult installation manuals", or similar.

I fixed this error condition so it's nicer now. But enabling --help
without config file installed will be much trickier. It will require
separate parameter handler I guess or much code complication.

Config is read first in order to drop privileges if DB=user before
parsing user input.

I fixed today similar problem with listing alphabets (-f alphabet-list)
before creation of state file.

I think that there might be more conditions like this. I've fixed
recently some problems with SUID user not matching /etc/otpasswd
directory permissions which still might die in a funny way. This is a
place to test currently. ;)

> 
> 3.  The next thing I did was to create /etc/otpasswd (with my UID),
> and truncated the otpasswd.conf file.  otpasswd started, but then
> assumed that I was using a global/MySQL/LDAP database, when, in fact,
> the configuration file was empty.  I think this is somewhat
> misleading.  I realize that there are global defaults, but I'm not
> sure that "DB" should be one of them.  I think there are certain
> things that should be explicitly specified.

I wondered about it today that if I have defaults for everything then
I might as well not fail if config file doesn't exists.

For now I'll change default from GLOBAL to USER, which is for sure
better default. If we decide on "required" options I guess DB must be
one of them and I don't have any ideas what else would have to be
required.

Also should we #-comment options in config by default? We can, but, no
idea. Also I'd be cool if you look at the comments in config and see
how can they be improved. ;-)

> 4. I should know this, but I keep forgetting to check the code.  Is
> there a "DEBUG mode" where otpasswd doesn't do actual syslogging?  In
> other words, where it just directs syslog messages to somewhere else
> (just to keep logs clean during testing)?  No big deal, I just thought
> I'd ask.  :-)

Utility never touches syslog now, logging can be reduced for PAM, but,
letmethingaboutit...

Ok, done. You can test it; now there's additional option which will
turn logging totally off (in PAM). I can change it still. It can log
nothing to syslog and everything to something like /tmp/otpasswd_log
this will be very dangerous option on production systems.
 
> 5. I tried using otpasswd while it was non-SUID, and running in my
> normal user context.  The otpasswd.conf file was created with my UID,
> too, so otpasswd should theoretically have been able to read/write it.
>  In this situation, otpasswd refused to run.  While I understand this,
> I think it's probably being a bit picky.  After all, if it *can* run,
> I think it *should* run.  It had sufficient privileges to update the
> various files, so what I would've expected is that it does what it
> needs to do, but warns the user that the utility would not have
> sufficient privileges IF it were run by someone else.  This would
> require checking the actual file on disk, rather than merely the
> setuid() functions.

It's question when to die with error and when to print a warning.

1) otpasswd is SUID root - currently this dies hard, but I guess I'll
change it as there's a reason to use it SUID root (and drop privilages
to user defined in config fast)

2) State is globally readable and we're not owner and can't do nothing
about it. (this currently doesn't fail)

3) In case of your configuration this currently works (I've removed
exit() from code), warning is printed but you still have to set the
USER option correctly in config as there's a check if the user matches.

4) Etc; I guess there can be more such combinations.

See what you think about it.

> 6. I can't remember exactly what I did next.  I think I set otpasswd
> to be SUID to my own user -- /etc/otpasswd and otpasswd.conf were all
> created with my UID.  In this case I believe that otpasswd also
> refused to run, because it just looked at the setuid() functions,
> rather than realizing that the executable actually *was* SUID, and
> *could* run as anyone.  It just happened that it was SUID to the
> person who was actually running it.

Yep, that fails. It's used kind of incorrectly and I've decided to be
on "the safe side" with such approaches and better die than do
something dangerous.

After recent changed this also just shows warning. I'm not sure how can
I securetly check if I'm SUID. I can't use argv[0] and assuming a
path is not nice either.

> 7. Next, I set the otpasswd.conf to "DB=user" mode, keeping otpasswd
> as UID to my user.  In this case, otpasswd did run correctly.
> However, I think it probably should *not* have run in this instance.
> After all, in the DB=user mode, it should not need SUID.  And, SUID
> (to me) would break functionality to anyone else (in addition to
> making my state information vulnerable).

It might be dangerous only if there's an early bug (in config parsing,
but since only admin might put something malicious into config this
really rather is not the case) but if DB=user is detected the
privileges gained via SUID are immediately (and permanently) dropped.
Therefore program will have access to user state files.

When being run by it's owner it's unable to notice that it's a SUID
binary as in previous question.

> 
> 8. I think that the --flag interface on otpasswd probably should
> accept key-value pairs.  I think that would give added flexibility,
> and probably clean the interface a little.  So, for example,
> 
>      $ otpasswd -f codelength:4
>      $ otpasswd --flag=codelength:8
>      $ otpasswd --flag=alphabet-size:43,codelength:5
I like the idea of ':' really. This can even be switched to '='. But
your third example is hard to code without major rewrite (getopt won't
like it). Still I can easily get something like this:
      $ otpasswd -f codelength=4
      $ otpasswd --flag codelength=8
      $ otpasswd --flag alphabet=3 -f codelength=5
      $ otpasswd --flag alphabet=list
(As the alphabet is precised by ID currently not by length).

What do you think?

> 
> 9. This was discussed in the other email, however I think that
> similarly the "contact" field should also be key-value pairs.  I'm
> noting this here merely to keep these thoughts in the same place.  :-)

True, but I have to leave implementation for later. ;-)
 
> 10. Regarding the --text and --latex options on otpasswd.  I think it
> would be nice to specify the number of passcards to be printed.  So,
> for example, assuming that --cards defaults to 6 (eg, for --latex and
> --text) and to 1 (for --key), then one would have a way to override
> the defaults.  IOW, to print no cards after key generation:
> 
>      $ otpasswd --key --cards=0
> 
> Or, to print just a single Latex card:
> 
>      $ otpasswd --cards=1 --latex next

I was thinking about 'range' support in passcard specification. So one
could do something like -t '[5:30]' to print 25 passcards from 5 to 30.

Currentl LaTeX implementation is not elastic enought to implement it
still. Adding backside with fingerprint can complicate it further.
Still -- idea is nice and worth implementation.

> 
> 11. I believe that there is a minor consistency issue with the use of
> the keyword 'next'.  In all cases where you allow a reference to a
> passcard, the reference contains brackets, I believe (eg, [current]).
> However, 'next' is a bare word.  It might add some consistency to
> optionally allow specification of the string [next].

Sure. Done. 
 
> 12. Again, as I mentioned in the other email thread, I believe there
> is a similar consistency issue with the passcode address.
> Specifically, whether a passcode should be referred to as CRR[#] or
> RRC[#].  I believe that the latter was the typical prompt that Gibson
> used, and the one that Tom Fors used, as well.  I believe this was the
> convention that developed on the newsgroup.  I think.

I'll try to implement this. I've added TODO entry to code currently.
 
> 13. I just want to clarify my understanding...  the new --remove flag
> *completely* removes a user's state information, correct?  So, if OTP
> is enforced, it is essentially like blocking his ability to login?  (I
> think this is good -- I just want to make sure I understand it)

That's it. If OTP is enforced user won't be able to login. (Admin can
decide to disable this flag when enforcement is enabled).

Just splitted this into GENERATION and REGENERATION policies, so the
user might be able to generate a key, but not regenerate or regenerate
if he already had state created by root.
 
> 14. In thinking about --remove, it occurred to me that it would also
> be useful to have an --init function, which creates a user in the
> database, and then initializes it to a default value.  If the user
> already exists, it would just resets the values.  But you're probably
> ahead of me on this functionality already.  :-)

Hm. otpasswd -k and answering 'yes' to first question and 'no' to
second would do I guess.

The second question is badly constructed nota bene.

> 
> 15. Is there enough tracking information in the user state to know how
> old the static password is (how long since its last change), and to
> set some system policy on how often it needs to be changed?  Perhaps,
> even keep track of the last password(s) so that the user doesn't just
> keep rotating the passwords?  I do think that there would be some
> wisdom in having a mechanism to encouraging the user to change static
> passwords every so often.

Hah! That's the thing I thought about adding to state and then totally
forgot. I want to include timestamp of static password creation. Then
later we can create policies for it (requesting reset). It's hard to
stop user from circulating passwords as we keep only sha256 sum of it.
He can go on with pas$w0rd1 pas$w0rd2 pas$w0rd3 etc. and it's hard to
detect. I guess at least it's not for current project state.

Normal passwd compares two passwords to each other current and
previous. That's something we can have in policy and would be doable
(as it might be required before spass is changed).

> 
> 16. Is there any similar mechanism to encourage a user to change
> sequence keys?  For example, suppose the admin noticed something which
> suggested a compromise...  or perhaps a tripwire alert...  would there
> be a way to set a flag such that everyone would be forced to do a new
> key generation?

It might be added easily added without tampering with state
compatibility as a flag. And is a nice idea. 

Also there's second thing I'd like to implement -- enable/disable user.
This might also be set as a flag and managed by root exclusively.

> 17. Suppose a new user added to the system.  Is there a way for the
> sysadmin to set a flag so that the *first* login is permitted with
> just the standard unix password, and a message is printed to alert the
> user to generate a key for subsequent logins?  Or, alternatively, each
> user could be given a one-time "initial login" password for OTPasswd
> for the same purpose.

I guess this is more otpasswd independent as in your second example.
Administrator generates user unix password and sends him over a trusted
channel both password and few passcodes.

> So.  Those are my thoughts, this fine, very cold January day.  :-)

I'll add my few:
- How will otpasswd behave if there's a perfectly valid user, then
  admin changes policy in a way which invalidates users state? How
  should it react? I'd add something like --policy-check which scans
  existing states, checks their validity, warnings, failures,
  recent_failures. Can automatically fix such user? This would very
  often change passcards, so rather no.


It's cold here also, and pitch dark. Night. ;-)

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

signature.asc
Description: PGP signature