[Otpasswd-talk] otpasswd talk [4] (previous was 3, not 2. ;s)

[Tomasz bla Fortuna]

Data: Sat, 5 Dec 2009 17:11:11 -0600
Od: Hannes Beinert <address@hidden>
Do: Tomasz bla Fortuna <address@hidden>
Temat: Re: ppp-pam


Hello!

On Fri, Dec 4, 2009 at 14:51, Tomasz bla Fortuna <address@hidden> wrote:
> Dnia Thu, 3 Dec 2009 18:32:17 -0600 Hannes Beinert
> <address@hidden> napisał(a):

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

That's a really good idea.  Maybe spit the passcard data out in some
pseudo-code, or XML, CSV, or something -- then let a little script
generate the pretty-print.  That way it would be easy to generate PS,
Latex, formatted ASCII, HTML, or whatever.

When otpasswd starts, it could scan a directory to see which scripts
are present, and perhaps call a registration function to get their
"canonical name", a one-line help text, a longer description, a
version string, and an author.  Maybe even some type of descriptor
array for options that are specific to that script?  Hmmm.  Overkill?

>> >> (2) The PAM module really needed more logging -- both for an
>> >> increased "paper trail" in the system logs, but also for
>> >> debugging.
[...]
>> 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).

You know, I never really liked the dont-skip option.  I don't think an
attacker should have multiple "bites at the apple" -- multiple
chances.  OTOH, the entire PAM stack will fail if he doesn't correctly
enter the static login password.  However, that's the entire point of
having a second factor, namely, that IF an attacker gets the login
password, he still has to get past the OTP.  And in that situation, if
the OTP is unchanging -- since it will not skip until he succeeds,
then it radically improves the attacker's chances.

The reason "dont-skip" was suggested, IIRC, was to prevent a DoS by
having an attacker spin through large quantities of OTP thereby
exhausting the user's available supply of passcards.  This is a valid
concern, but I don't think the correct approach is to weaken the
security of the system.

Once one has eliminated "dont-skip" for security reasons, it raises a
question of whether the (much safer) "repeat=x" option improves the
situation very much.  Basically, if one uses "repeat=3", then it does
limit an attacker to three chances at each OTP, but he can still chew
through many passcodes/passcards.  I think, for that reason, it
weakens the system too much without any real benefit.  Frankly, I
think OTP should be OT.  :-)

The issue of a DoS should be overcome in a different manner, I think.
First, I think it would be helpful to clarify some security policy
decisions:

(P1) Each OTP should only be exposed as a viable authentication
credential once and only once.

(P2) Any failure mode should result in the denial of an authentication.

Given this, how can one make #P2 as rare as possible for a legitimate
user?  To me, that's the real question.

For example, take the situation where the attacker has shoulder-surfed
the login password.  Now he runs home, and starts to try and
brute-force the OTP with a script.  With "dont-skip", then it's only a
matter of time until he succeeds (provided that no lockout feature on
multiple failures has been implemented).  Clearly this is inadequate.
OTOH, *without* dont-skip, then I could see two potential problems:

(DOS1) As above, successive OTP failures would exhaust the number of
passcodes the legitimate user has on-hand.

(DOS2) If there is an active brute-force break-in script running, then
the legitimate user AND the attacker could simultaneously get the same
OTP prompt.  And, since the script is faster, it would make a failed
attempt and bump the counter.  The legitimate user would never get a
chance to finish a login attempt.

It would seem that an out-of-band (OOB) solution, such as sending a
passcode by SMS, would help in the first case.  The problem is that if
that passcode is sent from the same passcode sequence, then if it is
"close" to the current passcode address (counter), then the attacker
could fail/skip that code without the passage of much time.  If the
transmitted passcode is "far away" from the current counter/address,
then "skipping ahead" in the passcode sequence would be necessary
(this may not be a bad idea, generally, but it shouldn't be done
carelessly -- more on that later [1] :-).

In the second case [DOS2], one could implement "locking" a specific
authentication attempt.  So, once a user is presented with a 3B[1]
prompt, he would be given the chance at completing that OTP login
attempt without any other login being given that same prompt.  I think
this would be easy to do, provided that there is no "dont-skip" or
"repeat=x" feature.  If such options did exist, then it would be more
difficult since passcode state information would have to be preserved
across login attempts.

For example, if two login attempts happen simultaneously, then there
are two cases:

(DS1) Both login attempts get the same OTP prompt.  This is
inadequate, since the first one to enter an OTP will consume the
passcode, which means that a brute-force script could easily lock out
a legitimate user.

(DS2) If each login attempt gets a different OTP prompt -- 3B[1] and
3C[1] -- then there are a number of cases:

(DS2a) They both succeed.  This is no problem.  Both passcodes are
consumed.

(DS2b) They both fail.  Not a problem.  Both passcodes are free to be
used again with dont-skip.

(DS2c) 3B[1] succeeds, and 3C[1] fails.  This is also not a problem.
3B[1] is consumed, and with "dont-skip" 3C[1] is not consumed, and
will be presented for the next login.

(DS2d) 3B[1] fails, but 3C[1] succeeds.  Now we need to consume 3C[1],
but save the fact that 3B[1] is still available.  This is a problem.

Naturally, this example could be taken ad absurdum.  It increases the
code complexity, and makes the system much less transparent.
Incidentally, just to be clear, I see "dont-skip" as a special case of
"repeat=x".

So, without "dont-skip" or "repeat=x", one can easily "lock" a
passcode for the duration of a login attempt.  This addresses [DOS2]
above, but we still have a problem with passcode exhaustion [DOS1].
I'm honestly not sure how to best cope with this situation.  It's
probably reasonable to make the policy decision that if the user has
no passcards available, then the only other alternative is to be
issued one using an OOB channel.  Given this, I see several potential
problems:

(OP1) The OOB passcode (PC) is in the same sequence, thus it is
conceivable that a brute-force script can consume the PC before the
user can use it.

(OP2) If the OOB PC is far enough ahead in the same sequence, then the
user must be able to enter a PC which "skips ahead".

(OP3) The OOB PC could be from a different sequence (a backup
sequence, or a sequence for OOB requests).  In this case, the user
must be able to indicate that he is entering a PC from a different
sequence.

(OP4) More generally, any OOB PCs must be entered differently, to
ensure that for any given OTP prompt, only ONE PC will be acceptable.
If this is not the case, then it would weaken the security.

I think that (OP1) suggests that an OOB request cannot simply send
"the next" PC.  That would only work under ideal situations.

In the case of (OP2) -- the state file could contain some information
related to the "rate" at which PCs are consumed.  It could then send a
PC *and* a passcode address (PCA) for a PC that is sufficiently far
into the future.  So, for example, if the system is consuming 15
passcodes a second, then the system could send a PCA & PC which is
generated from the current counter+13,500 (ie, counter+(15pc/s * 60s *
15m)).  Then, when the legitimate user attempts to login, he could use
the static password to "skip ahead" in the sequence.  For example, in
response to the OTP prompt 3B[1], he could enter something like:

     "xxxxxx/SKIP/978D3/OOBPC"

Where,
     /x+/ => static password
     SKIP => command
     978D3 => PCA
     OOBPC => PC

Once this passcode has been provided, the current counter value would
skip ahead to the next code after 978D3.  If one didn't skip the
counter ahead, then this passcode would be out there indefinitely, and
I'm not sure that's an ideal situation since it would weaken the
system, I think.  There is a remote possibility that this method could
exhaust the available passcodes too quickly, however.

Now, in the case of (OP3), two passcode sequences could be maintained
in the state file -- one for passcards, and the other for OOB OTP
requests.  This would create the extra complexity of having to choose
two sequences, but it would eliminate the need to try and estimate the
rate of PC consumption in the event of a brute-force attack.  Now,
suppose an OOB request is made, and the next PC is sent.  The user
could then enter it by using the static password, such as:

     "xxxxxx/OOB/3B1/passcode"

Where OOB is the command to indicate the specification of a PC from
the backup sequence.  I'm unsure whether it's preferable to send a
<PCA,PC> tuple for OOB requests, or whether just the PC is sufficient.
 I would also favor two additional safeguards to OOB passcodes
transmissions.  First, there should only be ONE valid OOB PC.  Ie, the
PC for the current counter value.  So, any OOB PC request would issue
a fresh PC, and invalidate any previously issued OOB PCs, even if they
are still valid.  Second, I think that since OOB PCs are, almost by
definition, "real-time" -- I think their validity should only be valid
within a certain time window.  For example, five minutes.  I think
that as a matter of policy, the OOB facility should not be used to
accumulate a stockpile of PCs.  That's what passcards are for, IMO.

My feeling is that if one were to implement the backup passcode
sequence, it would adequately address the issue of password exhaustion
(DOS1).  In addition, I don't think it would increase code complexity
too much.

[1] Let me get back to the issue of "skipping ahead".  I think this
can be a useful feature for passcard-based authentication requests.
However, for the same of security, I feel that the PCA of the new PC
*must* be specified.  To merely specify a PC would require the code to
scan ahead to find a matching PC in the sequence.  That will almost
definitely succeed.  Even limiting the lookahead window gives the
attacker too many bites at the apple.  If one doesn't use a PCA, then
it's like saying "please accept the passcode XXX which will follow
somewhere in the sequence".  It's more secure to make the claim
"please accept the passcode XXX which I know is at location PCA in my
code sequence".  This proves that you have/had access to passcards.
And, of course, when such an assertion is made, the counter must be
advanced to that address.

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

True.  However, in the case of SSH the sysadmin has made the decision
to allow this method of authentication, and the user then as two
choices -- either provide the private key which can (practically) not
be forged, or the user can screw up the SSH files to disable any
possibility of using SSH.  There is no way, with the SSH files in the
user directory, to "weaken" the authentication.  The user can disable
it, but not weaken it.

Of course, the user can be careless with the private SSH key, but
that's no different than an OTP user losing the passcards, IMO.

The difference with OTP is that the user could actually weaken the
system.  Now, suppose that each user's OTP state information were
cryptographically signed by a secret system key.  In that case, the
OTP system could verify the signature, and if it fails, it could just
disable OTP for that user altogether.  To me, this would be analogous
to the SSH situation.  I don't know if this approach would be
preferable, as compared to just keeping the secure information in
/etc.

The bottom line, to me, is that if the sysadmin has made the decision
to strengthen the system security by adding OTP, then a user shouldn't
be able to weaken the strength of that system.  Disrupt it, for
himself, sure -- that's okay (:-).

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

Absolutely.  I like the idea of having the option to disable passcards.

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

Yes...  I can't really come up with too many disadvantages, either.
Eliminating the SUID binary would be nice, although it doesn't *have*
to be SUID root.

The one example I could think of is a situation where a user does not
have access to root, and would like to strengthen his own account
access.  In this situation, one could conceivably write a non-PAM
authentication module that one could drop into a .bash_profile, or
whatever.  It would not be ideal, but I could imagine *something* like
this.

For example, if the sysadmin makes the policy decision that he will
not require OTP for the system, but individual users could avail
themselves of it as an additional step.  Perhaps the sysadmin could
allow the specification of a special shell in /etc/passwd, such as
"otpsh", which would execute the user shell if a user-level OTP
authentication has been satisfied.

Alternatively, I could imagine using the OTP code for securing access
to other user-level applications...  mysql?  I don't know.  But I
could imagine that there might be user-level situations in which
user-level state files might be useful.  Dunno.  I'm bending over
backwards to come up with examples.  ;-)

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

Yeah, you're right...

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

I think we're on the same wavelength.  As long as it parallels other
system functionality.

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

I *think* that there are some libraries which are more widely used,
but I think they are far from standard.  I think I've seen a Perl CPAN
module which can read Microsoft-style config files (the ones which
have [section] names, etc).  I think that module does the more common
key=value conf files, too.  But I don't know about a C library.

As far as user options are concerned...  you know what I think about
"skipping" (:-).  However, as far as any other options, I personally
think that there probably should be a negotiation between system-wide
setting, versus user preferences.  IOW, if the sysadmin decides that
users should not be able to select a SHOW setting, then I think the
user should not have that option.  OTOH, the sysadmin may have no
preference, and just set a mutable default as NOSHOW.  I think that
flexibility should exist for all options.

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

Wszystko w porządku.  :-)

I just wanted to make sure I understood.

>> 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 like that.  That gives the user/sysadmin real flexibility.

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

I think it would also be useful to keep track of the number of
failures -- to the extent that one could actually detect that the user
was trying to enter a static password.  It would need to be distinct
in some feature from a normal OTP.  My original thinking was that we
know the length of an OTP.  Anything longer would be an attempt to
enter the static password.  OTOH, a static password entry must follow
a certain syntax...  such as:

     <static entry>  ::=  <static passphrase> <delimiter> <command>

     <static passphrase>  ::=  Any char sequence longer than N >
     len(OTP)

     <delimiter>  ::=  Any single char not in OTP alphabet AND not in
<static passphrase>

     <command>  ::=  <command verb> [ <delimiter> <option> ]*

     <command verb>  ::=  SKIP |  OOB | LOCK | SEND | ...

     <option>  ::=  Any string not containing <delimiter>

So, if one has such a simple grammar, one could easily recognize the
specification of a static password/passphrase without ambiguity, and
then one could assess success or failure.

As far as specific <command verbs> -- I'm just throwing those out
there as examples of additional functionality one might want to have:

     SKIP  ==>  Skip ahead to some <PCA,PC>
     OOB  ==>  Specify an OOB password, either as <PC> or <PCA,PC> (?)
     LOCK  ==>  Completely lock the OTP system for this user
     (compromise) SEND  ==>  Send PC to the specified OOB channel

I'm not completely sure I like the details of what I've written, but
this is the general framework of what I was thinking.

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

Oh sure, otpasswd is still alpha/beta.  :-)  However, you do have the
state file version in the file, don't you?  I haven't had a chance to
look at the details.

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

I would be concerned that the "empty passcode method" alerts an
attacker that there is another potential avenue for attack.  I don't
know that this is a legitimate concern, though.

I *am* concerned that the static passphrase does not weaken the system
in any way.  As I've described it, I don't *think* it does...  but...

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

Agreed.  I don't think that any WWW interface should *return* an OOB
PC, or anything else which can *grant* access.  However, it would be
cool if a WWW connection over SSL could be used to initiate the
sending of an OOB PC.  As far as printing passcodes over a web
interface, I don't know.  Could that create a security loophole?
Possibly via the printing subsystem?  I think printing/creating
passcards will be a weakness almost no matter what is done.

> LDAP would aid it a lot. ;d

True.

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

Oh, man.  Did I waste your time in making that analysis earlier in
this email?  I'm sorry.  Things have changed in your README since the
last time I read it, I guess.  :-)

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

I read your email yesterday, and didn't re-read it today before I
started to reply.  I apologize if I've been redundant with many of the
things you've written here.

I think that the "repeat=x" feature weakens the OTP security even if
it's restricted to a single session (I hadn't understood previously
that you had restricted it to the session).

I really like the idea that the PAM stack is provided with a 2-tuple,
namely <UNIX PASSWORD, OTP PASSWORD>, and that this either fails or
succeeds, and the attacker can infer nothing about which passwords
were correct or incorrect.

And you're right, the MITM is a well-known risk.  The only way that
can be circumvented is through SSL or SSH, and I'm not sure there's
much one can do about that.

Incidentally, one issue that is popped up now and again is that some
people are eager that OTP authentication is only applied for WAN
logins.  IIRC, there is no way to do this within the PAM framework.
Have you thought about this at all?  For me, I generally use SSH
pubkeys for almost all my logins, with the exception that I like to
have one gateway exposed with simple login/otp authentication for when
I'm "on the outside" without a flash drive or laptop.  :-)

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

Hmmm.  You're right.  It has been a long time since I've thought about
this.

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

Well, that's certainly true.  Gibson basically rests the security of
the system on the choice of the *key*, and I think that once that is
chosen, it makes no real difference where in the range of the cipher
function one "starts".

Honestly, to me, I would be just as happy to choose a random passcard
in the entire passcode-space to start.  This would preserve the
"standard" and interoperable passcode addresses.  It is true, however,
that if one starts "in the middle" somewhere using the conventional
scheme, the passcard number could become very inconvenient to type.
Eg, if the PCA were 5E[346427837483].  Yuck.  :-)  That could make
formatting the passcards a little more difficult, too.

I suppose it comes down to whether one believes that the key-space is
large enough by itself to ensure sufficient security, and that one
doesn't really need to be able to use the entire code sequence (at the
expense of interoperability).  I don't know.  I do agree that there is
a large amount of "wasted entropy" at the tail-end of each code-space
which nobody will ever use.

Incidentally, there is another issue here, too.  In Gibson's PPPv3
implementation he scans the initial prefix of the passcode sequence
for each candidate key to ensure its "fitness" against strange
artifacts, duplications, etc.  One would obviously need to apply that
same logic for any new starting point in the code-space.  I remember
the discussion on the newsgroup, but I can't remember the specifics.
It's probably much more fresh in your mind.

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

Yes, of course, you're right.  I was sloppy with my terminology.  I
should not have mentioned an IV -- that's not really applicable, as
you say.

Okay, my memory is a little foggy, and I should really review the code
(or the spec).  Please, correct me if I'm misremembering.  The
Rjindael function has two inputs, the sequence key and the counter
value (plaintext).  The output of this is the ciphertext, which is
just used as 128-bits of randomness.  AFAIR, the sequence key is
essentially random, and the counter always starts at zero.

Now, the PPPv3 specification associates the first passcode generated
from the first cipherblock with the first PCA => 1A[1].  This initial
cipherblock is generated with a plaintext value (counter value) of
zero.  By salting the counter/plaintext, you are changing the mapping
to the PCA.  You are making the claim that this increases security by
making it harder for an attacker to deduce the plaintext.
Specifically, the attacker could no longer read the passcode address
and definitively know the counter value (plaintext).

So the questions are (1) does it increase the security in actuality,
and (2) does that increase in security justify breaking the
interoperability with other implementations.

I think you're correct about (1), although the fundamental weakness in
the algorithm is that once *any* plaintext value is found they are all
known, since the counter increases monotonically.  As far as (2)...  I
don't know.  But I suspect that the case is probably strong enough
that salting should be an option.

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

True.  Gibson argues, however, that cipher functions are essentially
just really good random number generators.  While this is true, I must
confess, that I'm not a cryptographer, and I don't know if there are
any fundamental conceptual flaws here.

Gibson is basically making use of the random distribution of the
output of the cipher function, as well as the 1-to-1 mapping between
plaintext blocks and ciphertext blocks.  Ultimately this last feature
was more useful in the earlier versions of the PPP specification.  By
using a cipher function, though, he has exposed himself to the
possibility that an attacker could make use of the reversibility of
the function, which is not a feature that is needed for PPP.  I
sometimes wonder if, at this point, one would not be better off by
using a strong cryptographic hash.  This would eliminate the
possibility of reversing the function, and the only remaining
vulnerability would be cracking the state file.  OTOH, using a
cryptographic hash would make collisions somewhat more likely,
theoretically.

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

Yes, I didn't correctly understand what you were doing by applying the
salt.

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

I looked at it yesterday.  It is nicely documented.  :-)

I agree with you, in that I don't like the idea of a pre-allocated
pool of passwords.  I, too, think that PPP is much cleaner.  I also
like the idea in PPP of maximizing the amount of OTP information in a
short number of keystrokes, and that the alphabet can be chosen to
suit any particular codepage/language/user.  Base64 is too limited,
and has too low an information density, IMO.

The race-for-last-key problem really only applies if an OTP is only
consumed on successful authentication (ie, "dont-skip").  If that's
the case, then it is a real problem, and his solution is not terrible.
 OTPW needs "dont-skip", because its pool of passwords is quite
limited, if I understand their scheme correctly.  With PPP, the supply
of OTP is so large as to be virtually infinite for normal cases.  This
lessens the need for "dont-skip" if one can address the password
exhaustion issue (DOS1).

You mention locking the state file -- and this is obviously necessary
to protect against corruption.  However, if one uses such a lock on
the state file to ensure single-threading of OTP authentication
attempts, then that would allow a potential DoS attack.  Someone could
simply not respond to the PAM OTP prompt, at which point, presumably,
the state file would be locked and nobody else could start a login.
OTOH, this may not have been what you meant.

As far as the prefix password in OTPW, that corresponds to the Unix
login password in the case of PPP/otpasswd.  So, from a conceptual
perspective, I don't see a huge difference in the security that OTPW
offers as compared to PPP.

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

I am somebody who always "lets the perfect be the enemy of the good",
as the saying goes.  You're right that going to that extreme isn't
essential.  It'd be nice, and maybe I might inquire on the pam-list,
but it obviously isn't a show-stopper.

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

Oh, absolutely.  Such tests are a good confidence test for both the
developer *and* the end-user.

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

Good question.  I guess the way I normally work is that I keep *my*
task list in the project files (TODO/etc).  I think that tells
everyone that those tasks (todo items) are on the developer's mind
already.  And, I generally think of Savannah's task list as useful to
communicate with users, and for users to propose changes.

OTOH, if a project is large enough, and has enough developers, then
that may not be good enough.  At that point, probably everything
should go onto Savannah's task manager.  But this isn't a very large
project, so I think the way you're doing it makes perfect sense.  :-)

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

I've worked with autotools quite a bit, and I still think they're
magic.  :-)

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

I've been reading about GIT...  I must say, I like it better than CVS
and SVN.  There's something very pragmatic in the design, which, I
guess, doesn't surprise me knowing who wrote it.  :-)

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

Exactly.  I've heard some horror stories about Docbook, but the idea
that it can generate all these various formats is very cool.
Especially since GNU wants info files, it would be very sweet to only
have to do this once.  One of the things that really annoys me is when
different documents are out-of-sync with one another...  the man page
is different from the info manual which is different from the PDF.
Theoretically Docbook addresses this issue.  OTOH, I know very little
about it.  But, I have a Docbook.  Book.  :-)  I've been meaning to
read it for a long, long, long time.  ;-)

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

You've been working very actively...  I just refreshed my (new) local
repo, and all kinds of changes came in.  :-)  I'm going to have to sit
down and read exactly what you've written so far.

I also think a man page for the state file would be useful.  And, as I
said, I think that the coding standards for GNU projects want info
files, although I didn't read that document very thoroughly.

> 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

I was actually very surprised, too.  I thought that there would be
some solid, robust, standard implementation somewhere.  Instead, I
found a whole pile of projects which did half the job, and weren't
very well publicized.

It would be very cool if one could put a project together which would
support major architectures, such as ia32/64, major OSes, such as
Linux, BSD and OSX, and with a variety of packages (deb, rpm, dmg,
fink, whatever).  Lots of work, to be sure, but this would be the only
project that would have taken it to this level.

> BTW. What's your timezone?

I'm about 3 hours north of the city with the largest Polish population
in the world (outside of Poland).  :-)  I'm in the US midwest (GMT-6).

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

That sounds like a pretty good idea, if there are enough functions
that are shared.

Once again, I'm sorry for the long email.  Sometimes once I start
typing, it just comes out.  :-)

Have a good weekend!

Hannes.

signature.asc
Description: PGP signature