[Otpasswd-talk] Some questions

[Hannes Beinert]

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.

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.

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.

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

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.

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.

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

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

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

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

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

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.

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)

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

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.

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?

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.

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

Hannes.