[Otpasswd-talk] otpasswd talk [2]

[Tomasz bla Fortuna]

Data: Fri, 4 Dec 2009 21:51:02 +0100
Od: Tomasz bla Fortuna <address@hidden>
Do: Hannes Beinert <address@hidden>
Temat: Re: ppp-pam


Dnia Thu, 3 Dec 2009 18:32:17 -0600
Hannes Beinert <address@hidden> napisał(a):

> On Thu, Dec 3, 2009 at 07:38, Tomasz bla Fortuna
> <address@hidden> wrote:
> > 2009/12/3 Hannes Beinert <address@hidden>:
> 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.
Yes, that for sure doesn't have a big priority. It'd be even possible
to write python script to generate ANY output out of plaintext
generated with -t option.

> 
> >> (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.  
There're some things to investigate. PAM_SIMPLE maybe passed by
application and is treated kind of separately. I don't parse argv for
it.  I thought it's automaticall but I haven't checked for sure.
Implementing "debug debug" is pretty easy; there're already levels of
errors implemented by mostly it's NOTICE and ERROR. I rarely use WARN.
This can be improved thought.

> My feeling is that one can never have enough when one needs it.
True. Also I'd like to make it as configurable as possible. That's the
reason for the 'dont-skip' option for example which I don't particularly
like. repeat=x is better, I have to check also how does it interact
with each other (should be ok. But it would be great to have testcases
for such behaviour also).

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

Currently it resambles .ssh directory where ssh also keeps user related
data which is used for authentication (authenticated keys).

I really like the idea and I'm thinking about it. For example with such
file you could deny printing of passcards at all. If user can print
passcard - he can loose it, ignore it, leave it open on his desk. If
server has good 'second-channel-communication' it can use it
exclusively. The skipping backward problem you've already mentioned,
having access to the file allows user to make a copy of file, publish
it 'accidentally' somewhere.

I wonder if it's worth keeping functionality of state files in
user homes if second approach would be working. I can think of one
advantage only - no SUID binary.

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

It kind of depends. In /etc/pam.d there's specific PAM configuration,
but conf files of modules themselves are scattered around /etc.
pam_unix uses /etc/passwd and shadow, /etc/login.defs; also
there's /etc/shells, /etc/securetty, and /etc/security with for example
pam_env.conf on my system, access.conf being config of pam_access.so
etc.

I guess we can keep all the things in /etc/security, this would be
otpasswd.conf and otshadow (I thought of otshadow because this file is
not world-readable like passwd but rather reminds shadow file; but, it
doesn't really matter), or we can keep config in /etc/security and user
data in /etc/otshadow. 

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

True. Even current version allows to overwrite some of user settings
(not-skipping, not-showing) this would just move files elsewhere, allow
to comment them. Is there any standard library to read this files (# -
comment, VARIABLE=VALUE kind?).


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

True. I meant 10-and-more. As you've possibly noticed I'm not a native
english speaker. Docs will require a review. ;)

> 
> 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 thinking exactly the same. Just some script somewhere which could
be passed contact info + login data. PAM module would have to check his
uid, if it equals 0 drop permissions to nobody, fork and execve.

User used for running script might be selectable.

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

I'll add quite fast some fields to state file. 
- SHA256 of static password
- Number of times static password was successfully used

Currently I don't bother with backward compatibility of files and I
prefer to put there anything we will really need. There's also number
of failures, but not yet implemented.

This commands would have to start with a character that is not used in
passcodes; or maybe an empty passcode would be sent first to state that
we'll be entering a command. SKipping ahead with SSH is not necessary
but kind of nice.

Some WWW interface for managing passwords would also be nice. This
passwords can be used to implement access to "something", users don't
have shell access but can print passcards, skip ahead with some WWW.

LDAP would aid it a lot. ;d
 
> 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.

Illegible passcodes that's a thing I remember also, but they are not a
problem unless "not-skipping" is enabled.

This skipping feature is strange. I've implemented it because it was in
ppp-pam, but it either makes a security hole (important one also)
making one-time passwords multi-time passwords or doesn't aid the DoS
problem (described in README).

I think about disabling it in future. repeat option can help here. It
allows to enter the same passcodes 3 times, but only in single session,
so to circumvent otp (guessing real passcode before user logs in) one
would have to perform man-in-the-middle attack on this session... which
he can do in spite of any otp.

> 
> 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. 
To be accurate there's Initial Vector for the algorithm which is not
used in PPP (I guess it's zero values), a key (sequence key) and
counter. Instead of using this salt in counter I could just generate
this initial vector, but that would make the system even less
compatible.

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

True. But who'll do it? If the user uses up 100 passcards (starting
from 1) in his whole otp-history all the time 115 bits of counter are
totally unused and zero. To achieve something I'm trying to achieve
with this salt you'd have to skip to
2430588335149560453309818624512630081 passcard atleast (to make the
last bit equal 1)

> 
> 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. 
Not exactly. If attacker intercepts some passcards he knows:
1) Exact counter values without any doubt - whole 128 bits which were
used during encryption
2) Most of bits (depending on passcodes length and alphabet) of
encrypted block of bits

The only thing he doesn't know is the IV (key really). In cryptography
it's pretty common way of breaking a cipher - forcing second part to
encrypt something you know (it was done during II world war when they
tried to break Enigma). Knowing the plain-text (counter) helps a lot
for some ciphers to break the key. The question is if Rijndael will be
susceptible to such an attack in future (Because there are no known
methods of this attack today). 

Nevertheless it worried me a bit that we're not using the cipher as it
should be used (so the attacker knows cipher-text and nothing else).
This can always led to some problems.

> 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.  :-)
Think about it I can be wrong also. I don't suppose storing it
separately, that's why I incorporated this into counter itself, just
about making it difficult to break key knowing passcards (and if we'll
implement kind of /etc/otshadow then we want to hide key from user
also. That's a bit extreme example but user might generate 2^32
passcards and finally break the key having a lot of clear-text <->
cipher-text pairs).

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

Take a look; I haven't investigated sourcecode but I don't like it's
idea as much as PPPv3. This uses limited number of passcodes stored in
file, made with base64 of random data. Secure for sure (no statistical
connection between passcodes if RNG is good), but not so neat. It uses
STRANGE password locking to prevent DoS asking for 3 passcodes if
user logs on often. 

I thought about they approach and I don't understand why secure locking
of state file don't solve this issue.

http://en.wikipedia.org/wiki/OTPW (here's some detail).


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

This naming-conflict could be solved, but still we'd have to interfere
with system.
> 
> 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.

I can understand that. ;-) Still great idea. 
> 
> 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.
True. Hm. Well. I wonder if it's worth the trouble. I'd create a good
set of testcases for authentication algorithm to be performed offline
with some non-pam code. This can be tested before installation. When
it's ok, we can install otpasswd under some bogus name in /etc/pam.d
like ot-debug-passwd-xqertte and use some automated online PAM test.
This will test most of the code without getting into _big_ trouble.

It's not perfect I know. ;d

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

True. Currently I was writting them more "for myself" to ensure the
interface is correct before finishing some part. I guess they should get
obligatory run after compilation and in case anything fails - ERROR.

Still I like the idea of being able to run them anytime with --check.

> >> 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.
Yeah, they can be nice. I've already added some things to
ChangeLog/TODO. Should I use Savannah bug tracking rather than this
file? 
 
> > 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.

Yep. Compatibility is always nice and, hm, transparency, and simplicity
of this algorithm is very neat.

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

I learned cmake for this project explicitly. :D It wasn't hard.
Previously I just wrote Makefiles myself and I've never ever touched
autotools. They're too much magic. :P

GIT is nice and if you're used to svn it really doesn't change much.
It's distributed FINE, but we won't be using it in distributed way.
Savannah has central repos (BTW, you have to set your ssh keys there to
use GIT, see FAQ or ask if in trouble I've got through it already) and
you just use git push to push changes there and git pull to get newest
tree. ;d All the time you can change something in project, and commit
(usually with -a) locally. I guess we won't use branches or anything
like that. 

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

I started to write man page. It's not in repos but it doesn't have
anything interesting in particular. I guess man pages can be written by
taking some example out of the net and changing it. No experience with
Docbook. It can generate manual, info files, html, latex or really
anything from it's files? It would be cool. Otherwise people are always
not happy. Man? Why not info? Info? Why not man? etc. 

I'm going to write one section more to README... this can be
incorporated into any documentation then. Hm. We would need:
man page for utility
man page for module (it's parameters, possibly config file contents)
current readme description of algorithm.. also accessible as a man
page? No idea. I can write LaTeX though. But it's not ok for such
system docs.

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

I was kind of surprised when I decided to enable OTP on my servers that
it's so uncommon. I hope we'll change it. ;d


BTW. What's your timezone?
BTW2. I think also about splitting project and creating some library
with functions common to utility and pam module. Testcasing of such
library might be easier then, but I wonder. Current approach is not
very good but it's not bad, it's simple and it works.

Cheers,

signature.asc
Description: PGP signature