[Otpasswd-talk] otpasswd talk [1]

[Tomasz bla Fortuna]

I cite whole first mail in this forward with my replies. Hannes and me
is discussing details of correct otp implementation. Part 1.


Data: Thu, 3 Dec 2009 14:38:15 +0100
Od: Tomasz bla Fortuna <address@hidden>
Do: Hannes Beinert <address@hidden>
Kopia: address@hidden
Temat: Re: ppp-pam


2009/12/3 Hannes Beinert <address@hidden>:

> It has been a long time since I've spent any time thinking about this
> project, however there were a few features I really wanted to add.
>
> (1)  I wanted to eliminate the need to use the ad hoc HTTP server to
> produce passcards.  Instead I had intended to generate a postscript
> file (and/or formatted ASCII).  I was extremely pleased to see that
> you had already made this improvement!

It was seemed obvious and necessary feature for me. Still also this
feature requires improvements in my opinion:
- add a background color for passcard titles
- maybe some borders around passcards
- fix whitespace so it's easier to cut

Currently passcards are in \begin{verbatim} so I don't have to escape
special characters - which will complicate this a bit... But these
aren't most important. ;)

> (2) The PAM module really needed more logging -- both for an increased
> "paper trail" in the system logs, but also for debugging.

There's more already. But I haven't taken time to check if everything
is logged correctly, what information should be added or which removed.
"debug" option will turn on a bit too much logging.

 syslog logging in pam_unix seems to be technically realised in the
 same way as in print.c so.

> (3) There was a problem with a return code in the PAM module which
> prevented it from working on one of my systems.  I can't remember
> precisely what the problem was, but I do remember that I rather
> unceremoniously hacked the module to provide a successful return code
> in a way that worked.  I was never satisfied, however, that the module
> was providing return codes that were correct with respect to the PAM
> specification.  A close scrutiny of the module was on my to-do list.
> :-)

Heh. ;)

There's much too much PAM error codes. I was quite hesitant which
should be used and what's the difference between some of them.
I've even noted (some of?) them while coding this part:
PAM_AUTH_ERR, PAM_CRED_INSUFFICIENT PAM_AUTHINFO_UNAVAIL
PAM_USER_UNKNOWN PAM_MAXTRIES

AUTH_ERR,  USER_UNKNOWN, _IGNORE are used. I even used MAXTRIES
but then removed it. I'm kind of unsure where does it play role in PAM
authentication scheme. That's another place which can be improved. ;d

> (4) I feel that keeping the state file in the user's directory
> hierarchy is a useful option, however I also feel that it would be
> good to allow a sysadmin to keep all user state files in a system
> directory, such as /etc/pam.d/ppp/user.  Depending on a system's
> user-base, I think that having the state file under user control might
> be problematic.  For example, if a user has control of his state file,
> then the user could easily cause the reuse of passwords.  This could
> be a problem if it violates system policy.

Agreed. I thought about this when deciding on passwd-like syntax of
state files. This would require some work, although I guess it's worth
it. Utility would have to be SUID, opening/locking in the beginning,
dropping permissions, doing it's work and closing file.

As the program is currently written to prevent any sigsegv because of
illegal user input it can be done without a major rewrite. Yet the
security would really have to be reviewed. I guess /etc/otpasswd would
be a good place for this global
database. Also... we can use mysql and/or LDAP. ;d Which would allow
this system to be used for web authentication also.

It's pretty obvious the program will need some config file in /etc to
implement all this features. System policy settings, and some PAM module
parameters could be
moved there too.

> (5) I *really* like the notion that a cellphone (or any other device
> capable of receiving text messages) is a wonderful alternative to a
> dedicated security token.  The idea of sending an OTP via SMS has
> always appealed to me, and was on my short-list for future work.  As
> you mention in your README, one of the issues with an OTP system is
> the DoS which can result when someone tries to brute force the system.
>  It occurred to me that one way around this would be to allow a
> special static password, accepted at the OTP prompt, which would then
> initiate the transmission of a fresh OTP to the previously arranged
> messaging device.  This could prevent a remote user from being locked
> out, either through some intentional or inadvertent DoS, or in the
> event the user forgot his passcard.  I haven't spent a great deal of
> time thinking of all the security implications, however some system
> like this would be very welcome.

Just added into this README file:
3) By enabling yourself to receive a next passcode anytime via a secure
   channel which cannot be blocked by attacker (like SMS).

   In some scenarios DoS also can be performed. For example if we'd use
   a free SMS gateway, attacker who'd know our phone number can use it
   himself to send you few tenths of any messages consuming limit of
   SMSes/phone number/day.

I was going to implement this scenario but I was not thinking
previously about static password. I just thought that passcodes are
<2;16> character long so one can type magical '.' to send him SMS.
That's ok if channel can't be blocked and is secured from spamming (1
sms per 5 minutes for example) but I guess in some circumstances this
might be just a little more complicated DoS problem.

Currently I have .php script to send SMS using simple static password.
It works but could be nicely incorporated.

> (6) While interoperability with other PPP systems is not really
> essential, the well discussed nature of it is quite appealing to me.
> I've always thought that extensions to the system should be optional
> (either at compile-time or run-time), but either way, it would be nice
> to see if they could get Gibson's blessing and be included in his
> discussion of the system.  One advantage of this is that if someone
> else writes a OTP generator for a portable device, for example, it
> could then seamlessly be used with any implementation.  If Gibson is
> unresponsive -- which is entirely possible given that he has other
> fish to fry -- I think that documenting the modified specification in
> some Well Known Place(tm) would be ideal.

I've sent already a message to him (yesterday) at address@hidden
I couldn't find anything more appropriate and couldn't set up their's
groups.

My mail was mostly asking about his thoughts on "salting" counter and I
gave him information that another implementation was created.

When salting is disabled this system is directly compatible with PPP
(there's testcase that checks few selected passcodes of different sizes
and alphabets and SHA256 sum of some passcards), with salting any other
PPPv3 system can be made compatible by skipping some number of
passcodes (prompts wouldn't match though)

I'll try to move some info to savannah page. I'd create a page on
standard wiki. OTPW has
there pretty lot's of information about their implementation.

>
> (7) As I mentioned above, when I patched ppp-pam, one of my concerns
> was that any new code I added would remain compatible with the
> specification, and that nothing I added would break the backward
> compatibility with previous versions of the specification.  As a
> result, I added a bunch of unit tests to the autoconf makefile.  One
> of the things I really wished I could do is test the actual pam module
> in a "real" environment.  As a result, I added a version of the actual
> PAM source and a utility called pamtester to the project source so
> that the actual (newly compiled) PAM module could be tested.  I liked
> the fact that I could test the module, but the implications for the
> project, the compile, and the tarball were really awful -- a really
> awful gross mess.  I came to believe that one of the things that the
> actual PAM project needs is some type of simulation mode for exactly
> this type of situation.  There was actually a fellow on the pam-list
> who seemed to be working on something like this, and Thorsten Kukuk
> *appeared* to be open to it, however I never pursued the matter.  My
> concern ultimately rests with the ability to have some confidence that
> the PPP pam module actually performs as it should in a production
> environment without first requiring its installation.  The idea that
> it is necessary to install a piece of security software and simply
> hope for the best is, IMO, suboptimal.

Testing PAM  authentication _with_ PAM is great idea! Currently there're
only two testcases of authentication which work with a simplified PAM
code.

I guess putting /etc/pam.d/otpasswd-login itself is enough to use it
for PAM authentication without changing configuration of SSH for
instance.

There's one commented out testcase of bit distribution in passcodes
generated using 88 long alphabet. For 64 alphabet it's pretty fine but
I wonder if everything
is ok for this 88 alphabet. Gibson was also doing such a testcase and
I'd like to
compare results in future.

Also testcases just print if they succeed or no. I thought about
creating a global
counter of failed testcases and print something more visible if anything
fails.

> I'm sure I could come up with some more thoughts, however I've
> probably already bored you for long enough.  In addition, the copious
> notes I've kept on this project are on a development machine which is
> currently unavailable.  :-)

I'm open for development! I'll have much less time currently (and in
the near future)
than I had during this week but I'd really like to make this project
kind of "enterprise-ready". Thing which I guess was impossible with
ppp-pam implementation.

> In any event, I hope to install your project very soon, and perhaps
> I'll be able to contribute in some way.  You've done a very nice job,
> and I am very pleased to see this project come into existence!
>
> Thank you for your efforts!

And I thank you for your support! I was nothing like expecting so
interesting and to-point reply so fast. My main email address is
address@hidden and I guess I'll be switching to it in future
conversations.  ;d

Cheers,

signature.asc
Description: PGP signature