[Otpasswd-talk] Fixing the dont-skip approach safely + OOB

[Tomasz bla Fortuna]

Hi,
  we've found some idea which can fix don-skip option in a cheap way
that doesn't require much changes inside the implementation and will
allow long time OOB.

1. How does it work now.
Each time user is presented with prompt the passcode is already
reserved for him - used up. Any number of parallel ssh connections
won't use the same passcode.

This secures us from race-for-the-last-key attack as long as our
channel (i.e. putty) is safe. So not only keylogging problem is fixed
but also active keylogging + killing our connection and using just
entered passcode in separate channel is fixed.

This enables attacker to do DoS attack if he known Unix password or
it's not required (or rather it's required, and not requisite.)

2. How we tried to fix it.
ppp-pam had dont-skip option which caused passcode to be valid until
correct authentication is done. This was flawed on many levels. Opening
in parallel 10 ssh connections would result in being presented with the
same prompt and the same not-so-one-time passcode would authenticate
all sessions.

Also attacker has more chances to break passcode.

After implementing dont-skip in other way: reserving passcode, if
failed - releasing if authenticated - using it up I've noticed that it
doesn't solve the problem it tried to solve:
A logs in reserves passcode
B logs in reserves passcode
A fails, but can't release passcode as the counter incremented already
B fails and releases passcode.
Each such series would use up one passcode.

3. How we can fix it.
For each logon use two passcodes. 
a. Counter=1, current passcode = A
This passcode is totally dont-skip. No reservation is done, Multiple
users might log on, all will get the same login prompt, but - only one
of them will succeed:
I. Read state detemine prompt
II. Read passcode from user
III. Lock state, check if passcode matches if it does use it up and
unlock state

This approach itself of course would allow race-for-last-key attack
when attacker using active keylogging can hit "enter" with correct
eavesdropped passcode before user is able to do this.

But then magic happens! :) Users are informed whether this passcode was
entered correctly and if it was, the user is presented with prompt for
the NEXT passcode. And this one is reserved as in 1). That is - only
this user on this channel can use this passcode. If it was attacker who
managed to sniff first passcode now he is left alone. User won't enter
next passcode because he was informed his previous trial failed.

If it was user who entered passcode - he just enters next passcode. 



Summary:
This approach can also be used for long-time OOB when user is sent two
passcodes with OOB communication. Attackers won't be able
(statistically) to use this pair before he manages to login so DoS
condition is kind of fixed. Also he is saved from active eavesdropping
at the same time.

Two passcodes should be of equal length so passcards can be kept simple
and we keep compatibility with some pppv3 devices which don't change
this size automatically (althought it might be easy to drop visually
some characters from passcode). Yet this two passcodes can be shorter.

Default alphabet (64), 3 characters give 262144 combinations. After
some time first passcodes can be broken, but then attacker has once
chance to guess password with 1/64^3 probability.

This can be used as a 'dont-skip' solution or only with OOB.



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

signature.asc
Description: PGP signature