[Otpasswd-talk] otpasswd talk [2]

[Tomasz bla Fortuna]

Data: Thu, 3 Dec 2009 18:32:17 -0600
Od: Hannes Beinert <address@hidden>
Do: Tomasz bla Fortuna <address@hidden>
Temat: Re: ppp-pam


On Thu, Dec 3, 2009 at 07:38, Tomasz bla Fortuna
<address@hidden> wrote:
> 2009/12/3 Hannes Beinert <address@hidden>:

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

I wish I knew more about Latex, although I do have Knuth's complete
series of Tex books upstairs.  :-)  In any event, though, I think that
what you've done is excellent.  Basically, you've created a framework
that other people can tweak and improve with patches.  I think it's
smart to just leave these sorts of things as they are, for now, and
let others (possibly me) submit patches.

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

That is one thing that bothered me with ppp-pam, namely that the
"standard" PAM options weren't present.  Particularly I missed the
existence of "debug".  It might be worthwhile to have several levels
of debugging output...  "debug" would enable some reasonable
compromise level, and then "debug=2" (or "debug debug" or "debug=dev"
??) would provide more.  My feeling is that one can never have enough
when one needs it.

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

Honestly, I do think it's worthwhile -- especially in light of your
comment below that you would like to make this project "enterprise
ready".

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

I'm torn -- usually PAM module configurations are placed in
/etc/pam.d, aren't they?  OTOH, this concerns a fairly integral
authentication mechanism so perhaps you're right that it should be
/etc/otpasswd.  Oh well, that's trivial enough.

As far as LDAP -- absolutely.  I think that would be *very* cool.

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

I think so, yes.  Much of this comes down to whether one views
PPP/otpasswd as adding a layer of protection for an individual user,
or for the entire system.  In the latter case, the user shouldn't be
able to undermine this layer by poor judgment or poor administration.
Since users are typically bad at such things, unless they also happen
to be the sysadmin, I think I prefer aiming this system at the
sysadmin.  Thus, the configuration settings shouldn't be under user
control.  This was one of the qualms I had with Tom's implementation.

>> (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'm not sure you mean "tenths", do you?  (tenth == 1/10).

I think that no matter which out-of-band solution one chooses, there
will be a way for a determined attacker to implement a DoS.  I think
the issue is really that the more channels one provides, the less
likely that s/he will be able to block them all.  If a moderately
general out-of-band solution is used, then the user can use as many
approaches as necessary to address his threat model.

Suppose otpasswd were to implement a very general framework to send
out-of-band passwords to the user, one could then implement, for
example:

(1) SMS to a preexisting cell number,
(2) Email to a preexisting email address,
(3) Retrieval of OTP from a one-time randomized URL,
(4) Telephone callback using text-to-speech engine,
(5) Text page using SNPP, or etc.

And I'm sure more possibilities exist.  If the framework were to be
flexible enough, then this functionality could be implemented with
Perl, or some other scripting language -- almost as a plugin.

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

Well, by using a semi-static password of some sort (ie, some type of
simple authentication mechanism which a user can be expected to
remember), it would address the spam issue.

My original thought when I was hacking at ppp-pam was to use a
"static" password to gain access to a limited set of additional
functionality.  This password would have to be reset periodically, so
it wouldn't be permanent -- possibly each time the user exhausts a
certain number of passcards, for example.

In any event, I was toying with the idea that when the "3B [1]" OTP
prompt is given, one could enter the password, plus a specific
predetermined function.  For example, one could enter "xxxxxx:SMS2",
where /x+/ is the static password, and "SMS2" would instruct the
system to send a single OTP to the second configured cellphone.  Other
functions could be similarly implemented.  In each case, though, the
details of where the OTP would be sent would have to be
pre-configured.

One reason I thought this mechanism would be useful is that it could
also address one additional feature which Gibson talked about in the
podcast (or someone possibly wrote about on the newserver), namely,
one use this technique to tell otpasswd to skip *ahead* to a specific
passcode.  So, for example, in response to the OTP prompt, one could
enter "xxxxxx:SKIP:1A2" to skip to the second passcard, code 1A.
There were some specific reasons I -- and others, as I recall --
thought this would be useful, but right now I can't remember them.
One reason might be if a portion of a passcard became illegible for
some reason, and the user needed to resynchronize the server's
position in the passcode sequence with the passcard information that
was in the user's possession.

In any event, these are/were just thoughts.

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

Excellent!  I'll very curious to see if, and how he responds.

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

My guess is that Gibson would say that salting isn't necessary insofar
as it doesn't buy you any additional security.  Specifically, from the
perspective of "standard PPP", each sequence of passcodes is uniquely
identified by the initial vector provided to the Rjindael cipher, and
a passcard/passcode address.  This is what makes all the PPP systems
interoperable.  However, one could start anywhere within the
passcode-space by simply starting authentications with a random
passcard/passcode address.  The passcode space is certainly large
enough.

As you wrote, by using an initial salt, you would only be changing the
mapping of the passcard/passcode addresses to the actual passcode.
This means that IF an attacker knew the Rjindael IV *and* they knew
the current passcard/passcode address, they would additionally have to
know the salt.  However, I suspect that Gibson would claim that this
doesn't add any security since any attacker who knows the IV, would
also know the salt.  This would only be false if the salt were stored
separately from the IV -- but if this were the case, then
administration of the PPP system would become difficult.

I think that salting the cipher is useful to intentionally "break"
compatibility with other PPP systems, but I'm not sure what other
advantages it has.

Of course, I could be very wong.  :-)

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

I should look at OTPW.  I didn't know about that project.

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

I'm not sure what you mean.  It's true that to test the PAM module in
a production environment (since there is no test, or "simulation"
environment) would mean that you would have to install the otpasswd
configuration files and the otpasswd PAM module.  At that point you
could use a special client to exercise the module with various tests.
This definitely would work, but it would also require a limited
installation *and* it would require root privileges.  In addition,
unless one used different names for the files, one would also risk
breaking a real working installation of, say, a previous version of
otpasswd.

When I wrote the unit tests for ppp-pam, I compiled a hacked version
of libpam which used library paths from shell variables, and I also
hacked various shell variables so that the dynamic linker would load
the modules from the correct places.  This way an unprivileged user
could test the newly compiled PAM module (which was not modified in
any way for testing) using the system's production version of libpam.
Now, while I was very pleased with myself that I was able to
successfully do this, once I stepped back and looked at what I had
done, I felt like Doctor Frankenstein.

What I think should really happen is this:  I think that libpam should
include a new API function called pam_test() that can be called from a
client, and which does several things.  First, it should ensure (fake)
every return status as a failure.  In this way, the API couldn't be
abused to put a production PAM module into test mode, thereby
circumventing any authentications.  In other words, if you call this
API function, you would guarantee that everything would fail.  Second,
pam_test() would be given a number of new paths for libpam to use for
dynamically loading PAM modules, for locating configuration files
(/etc or /etc/pam.d, or whatever), and etc.  I don't remember all of
the various paths that would need to be specified, but essentially
they would allow "relocating" the system paths to the test
environment.  Finally, the PAM API should include a way for the PAM
test client to retrieve the "real" status of a PAM call.  In other
words, the actual API function call would fail (for the sake of
security), but then one could retrieve the return status that libpam
*would* have returned in a production environment with a separate call
to the API...  perhaps pam_testrc().

Now, if these functions were included in libpam, then a very simple
PAM test client could test the newly compiled PAM module with the
*real* libpam, and apply intelligent unit tests.  Specifically, it
could test to make sure that there are no strange interactions between
libpam and the PAM module.  And it could do this without requiring any
user privilege, or without any change to the production environment.
And it would be "clean".  :-)

But, as I wrote before, this would require cooperation from the PAM
developers.  Sigh.

> 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 think that would be a good idea.  In the case of this particular
project, I don't think that any test cases should fail -- any single
failure should lead to a global failure, IMO.

>> 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'll have to review the notes I kept when I was hacking at ppp-pam.
I've probably forgotten some things that were fresh in my mind at that
time.

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

I really (really) like your ambition to make the project
enterprise-ready.  There are quite a few OTP implementations around
the web, but many of them are not well thought out, or they are not
well documented.  It seems to me that with all of Gibson's work, and
with all of the conceptual thought this project received on his
newsgroup, I think that PPP has already received a certain level of
security review.  If otpasswd could then add a solid codebase and good
documentation, I think that it could definitely become a de facto
standard.  I also really like the aspect that the PPP specification is
sufficiently well documented that there can be a high degree of
interoperability.  Specifically, the Java clients which exist could
allow some people to use their portable devices as security tokens --
and no otpasswd-specific application would need to be developed.  I
like that.

I have not used cmake or git very much, so I will need to acquaint
myself with that environment.  However, I would guess that almost
everything is easier than autoconf.  :-)  Once I get myself up to
speed, perhaps I can help out.

It occurs to me that I could also pitch in with some documentation --
man pages, etc.  It would also be nice to adapt Gibson's webpages into
a manual of some type.  I don't know how his webpages are licensed,
however.  Do you have any experience with Docbook?  I've always wanted
to learn it, but never really took the time.  I really like the idea
that a central document file could be used to create a number of
different derivative formats.  OTOH, I have also heard that Docbook
can be rather complex.

> 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

I really like PPP -- it's simple, it serves a real purpose, it adds
real security, and it seems to me that it is fairly well thought out.
Password security is too simple, and too vulnerable.  IMO Multi-factor
security should not need to be the exclusive province of commercial
interests.  There should be a solid, robust, and as you say, an
"enterprise-ready" FLOSS solution.  I think it would be really cool if
it could be this project!

Hannes.

signature.asc
Description: PGP signature