[Otpasswd-talk] otpasswd talk [5]

[Tomasz bla Fortuna]

Data: Sun, 6 Dec 2009 02:14:16 +0100
Od: Tomasz bla Fortuna <address@hidden>
Do: Hannes Beinert <address@hidden>
Temat: Re: ppp-pam


Dnia Sat, 5 Dec 2009 17:11:11 -0600
Hannes Beinert <address@hidden> napisał(a):

> Hello!
Hello! I've read your mail top-to-bottom and I'll try to answer as much
as possible. ;d

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

For today - overkill for sure. But one day I guess this can be done and
can work nicely. While in topic - I thought also about creating GUI
interface for utility. Hm. Priority would also be small, but it might
help propagating OTP as a good and secure auth method.

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

Yeah I'd never use dont-skip myself. 64alphabet with PC 4chars long has
16 777 216 combinations.

Probability of guessing with one chance is small .00000005960464477539
Probability of quessing with 3 approaches (repeat option) is also rather
small: .00000017881393432617

But giving attacker whole eternity for trials is not wise for sure. I
guess leaving. repeat option might be configured in a way that asks
user once again for passcode - but next one.

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

Yep. As you've noticed there's something in README on the topic. ;d
ppp-pam had quite big one-time problem. When user logged in, attacker
also could. Then he would be prompted the same passcode! After
observing what user writes, he could use the same passcode once again.

That completely spoils the idea of OTP.

After securing it like this:
1. Lock/Read state file
2. Increment counter
3. Store/Unlock state
4. Ask user for passcode
5. if Successfull - OK
6. if Unsuccessfull:
  read state once again to check if nothing changed in the meantime
  (somebody could be authenticating and he used up the NEXT passcode!)
  if something changed - we can't do anything.  We can't 'dont-skip'.
  if nothing changed - decrement counter and save/unlock

This fixed something but again made it vulnerable to DoS attacks!
Attacker with two parallel sessions could skip passcode. 

Here as you can see all locking/unlocking happens in short times and
therefore doesn't enable attacker to do a DOS by locking state.

Nevertheless I thought about locking auths when some auth is happening
already... still that's another DoS so I decided not to implement it.


Ok.  I'll try to describe while commenting a bit current implementation
and how it tries to solve some problems. I don't insist that current
solutions are always good.

> 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.
> 
> 
> (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.
DOS2 is currently impossible as passcodes are locked for a session;
that is - after user sees prompt that passcode is explicitly his. One
can use it only by performing MITM.


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

Such a passcode could also be "locked", like: user logs and locks
passcode. He doesn't have passcard with him so with some command he
requests an SMS. User receives it and types in received passcode.

While users waits for SMS an attacker might have failed to authenticate
hundereds of times.

Problem I see is with PAM login timeout. If SMS arrives to late
session might have ended. I guess this can be configured and by default
is for sure longer than a minute.

> 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.  
That's done. ;d

> I think
> this would be easy to do, provided that there is no "dont-skip" or
> "repeat=x" feature. 
repeat is safe here as it locks passcode for session, and user can type
it 3 times in one ssh session. If he breaks it he won't be given the
same passcode again.

But dont-skip is difficult to do here. And doesn't really help anything.

> 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.
That shouldn't happen currently.

> 
> (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.
True.
> 
> (DS2b) They both fail.  Not a problem.  Both passcodes are free to be
> used again with dont-skip.
But difficult to implement since one will fail first and must detect
that there's some other which might or might not fail. So basicaly it
must assume it might succed and we end up in DS2c.

> 
> (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.
Depends on order in which they fail. ;d True.

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

Which currently will cause (both) passcode(s) to be skipped. So DoS can
also be performed.

> So, without "dont-skip" or "repeat=x", one can easily "lock" a
> passcode for the duration of a login attempt. 
repeat is not a problem really, dont-skip is.

> 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.  
There's also a question about unix question being required or
requisite. I'm not sure if you're familiar with it.

If Unix password is required then attacker can used up passcodes
without knowing upass but he won't know whether upass he is using is
correct.

When upass is requisite failing to send a valid upass will fail
authentication and no passcode question will appear at ALL. Attacker
will know the upass he entered is valid (just like he would know it if
there was not OTP system - he'd just login).

Still having upass stolen may cause DoS condition.

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

Not if it's session-locked. Which I hope solves situation.
 
> (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".

Yep, quite difficult. BTW. when talking about OOB PC we have quite a
bunch of possibilities I haven't though about like OP3:
 
> (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.

This OOB sequence can be system-wide and not per-user even. This can be
automatic so user doesn't really care (he shouldn't). Still system must
know it's OOB comming it - it should.

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

I'd try to avoid it. I guess users wouldn't like it and/or understand
what's going on. I hope that it can be mostly automated - system has
sent some oob passcode and it knows which. Then the prompt instead of 
Passcode 3A[10]: 
can look like:
Passcode OOB: 
User gets sms and enters it.

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

Or system-wide which would be easier and not so impossible. But I guess
we can do it simplier.

> 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.
Doing this "for a auth session length" is simple, if it's not enough we
can think about storing some more information in state. That would be
more elastic. 

>  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.
True. Also doing so would be kind of hard. I guess there should always
be ONE possible passcode for a user. When user tries to authenticate
this gets locked and will either be skipped on failure or used for
successful authentication. This also doesn't create lot of problems.

> 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.
That's true. I also wonder if static password couldn't be used like
this. Some command meaning "just authenticate me". This would have to
use up static password totally so it's not used like this all the time.
This could be dangerous if user uses spass for some other command and
then attacker uses it to authenticate. 

> 
> [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".
Yeah I guess that should be impossible. Currently skipping can be done
like this:

reactor ~ % otpasswd -s '1230000' 
Skipped to specified passcode.
reactor ~ % otpasswd -s '[123321]'
Skipped to specified passcard.
reactor ~ % otpasswd -s'G5[123321]'
Skipped to specified passcode. 

This can be done also while authenticating.

>  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.
That would still give the attacker like 70 tries of a passcard in one
bite (more than reply option). ;D I guess this would have to use code
just. spass + code possibly.
 
> >> >> (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 (:-).

Agreed.


> although it doesn't *have* to be SUID root.
TRUE! We can have some non-root user for this. Still a mistake in
utility can invalidate whole OTP system (reading keys of different
users). Still that's not that bad (as having uid=0)


> 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.
>
Even if not enforced system-wide user could enable OTP for his account
by making entries with utility in global otp state files. Doable for
certain.

> 
> 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.
I guess I can write it. This won't even be difficult if we decide on
longest line in file which is "legal" (too long would simply cause file
too be invalid and return PAM_AUTH_ERR when authenticating).
> 
> 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.
With show this is implemented even. ;d By default it's user-setting,
which can be enforced in both directions.

> > 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.  :-)
Nie ma sprawy. (-;
> 
> I just wanted to make sure I understood.
Sure.
 
> 
> >> 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>

I'm afraid of getting too much obscure here. Passcodes might be 2 to 16
characters long, that would make static password pretty long by
default. One'd have to write full command, if he get's it wrong he must
reenter whole thing. 

Also I feel ok with  OTP being shown while written, but static password
never should. Also command could be shown to the user. What gives...

I thought about implementing it more as a chat. Since passcodes are
(2;16) if user just hits the enter (which is fast) or enters some
special char (predefined in program, not secret) like a dot.
he can get a spass prompt without "show" enabled. Then if the password
is correctly written he gets command prompt where <command> applies:

Passcode 5F[124]: .[ENTER]
Static password: [entering password, not visible, ENTER]
Command: SKIP:[123]  # giving number of passcard to skip to

Passing '.' for passcode might select OOB automatically (faster!) 
and passing nothing could enable Command prompt to do something more
advanced like skipping. Still skipping here is not that important as
user can do this with utility and OOB would have to be done like this.
That's why I'd like to make OOB prompt fast.

Discussion still open. ;d also I'd make it an option:
1. Always send OOB
2. Send if requested
3. Never send OOB

> 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.
I do. Just checking if it matches, but might implement "state update"
in future.

> > 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...
Think if my approach differs anyhow in weakening from yours. Static
password prompt might be shown always independent on the fact if
there's any spass set so attacker can't detect if it's being used at
all.

Also if user spass is keylogged attacker might skip out of the range of
user passcards enabling a DoS condition similar to many trials.
Securing skip with a passcode would solve this though. 

And we must agree if this spass is to be used only in trusted places or
not.

OOB could be send without a password if some DoS timeout is checked.

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

Not so bad it's good to rethink somethings from time to time. ;d And we
have material for -talk. :D I always try to read whole at first and
then to reply. But hell, there's lots to write/read. I guess it's
good. ;d


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

This is requisite/required question. I wonder still about requisite
implications and which I prefer (currently using requisite).

> 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.
I though about placing part of ssh key finger print on passcard. Easier
to check then


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

Just like me. :D I use keys (stored on encrypted drives) on my trusted
machines and from the bad, wild, outer-world I login with otp. Using
otp all the time would make me angry at it too soon I guess (which
would circumvent it's security; that's why I think this must be as
easy for user as possible).



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

Skipping doesn't help much here as the attacker still sees the counter
value in prompt. Passcards already cut number of digits visible:

reactor otpasswd % otpasswd -s 43789261234893237928017389021321
Skipped to specified passcode.
reactor otpasswd % otpasswd -t next                            
reactor [*560874784189113257391271734]
    A    B    C    D    E    F    G   
 1: 4s9g Efb4 address@hidden =yLu @s%5 address@hidden Xi26
(...)

reactor otpasswd % otpasswd -d "this made the label too big"
Flags updated, current configuration:
show dont-skip alphabet-simple codelength-4 (no salt)
Passcard label='this made the label too big', no contact information.
reactor otpasswd % otpasswd -t next                         

this made the label too big [*1271735]
    A    B    C    D    E    F    G   
 1: A%Nn Zb7a 33F9 LkV: EAv= q9== fR54
 2: 8zow yjaJ ++hr nc!3 Zdk! !+L9 +ScM
(...)

(2 hours ago I did 'next' finally working after skipping. ;d)

> 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.
I didn't know that! And I still kind of don't understand how it's
supposed to work.


> 
> 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.
I'm really not sure myself about (1). Cipher is not intended to be used
in circumstances where the attacker knows cipher-text and clear-text.
It's said to be secure, but one defines it's security in conditions
when it's is used correctly - attacker doesn't know clear-text.

known-clear-text and even choosen-clear-text attacks work for many
ciphers but I haven't found any information about Rijndael immunity
to this. I only found that XSL attack (which requires something
similar) can reduce rijndael complexity to 100-around bits. That's
still plenty, but a lot less than 256. Question is if in future such
attacks wouldn't be possible; 

> 
> > 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.  
Interesting idea... One could even just calculate SHA256 out of
key+counter 256 bit long data. Similar idea. I guess it suffers kind of
similar problems as rijndael here. SHA256 might be less vulnerable to
XSL.

> 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.
Not so sure about it. It's true that rijndael is reversable so 128 bit
-> 128 bit should ALWAYS generate unique data set. SHA256 doesn't
ensure that 128bit -> 128bits won't clash but I doubt this would lesser
security itself.

> 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.
I thought about this approach and immediately ceased it. Locking works
but it's always (lock, read, change, save, unlock) which just ensures
atomic operations.


> > 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.
Which would solve debian problems with openssl at times... ;-)

Implemented failed testcase error codes, enumeration and global
success/fail message already.

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

Ok! :D
 

> 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.  :-)
Agreed. ;d It works fine. And we can use it more universally. Like...
Somebody without r/w access to repository (which I guess you currently
posess. ;d) can clone repos from savannah, do his changes (lot's, many
commits etc.) Then I can pull the changes from him, review and if they
are good - push upstream to main repos. That way many can send their
changes in good way without being given r/w.

> 
> > 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 have to learn something for tuesday... tomorrow (gah, today as it's
2am) I won't have much time for otpasswd. Still I've cleaned up a PAM a
bit and cleaned up a bit code design. 

state.h/c is currently considered low-level and should only be used by
ppp.h/c this will ensure some security when reading/storing files.

PAM works this way, but utility doesn't still.

> > 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).
That's why you know some polish phrases, do you? :D 

7 hours of difference, quite lot. 

> > 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.
Lot's of really.

> Once again, I'm sorry for the long email.  Sometimes once I start
> typing, it just comes out.  :-)
True!
 
> Have a good weekend!
Half of it passed me already. ;d
Have a good time!

-- 
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl
pgp: 0x90746E79 @ pgp.mit.edu
www: http://bla.thera.be

signature.asc
Description: PGP signature