Re: [Otpasswd-talk] User state information & OOB usage

[Hannes Beinert]

In the past when I've written to the mailing list, I've not cc'd you.
Perhaps the mailing list is uneven in its delivery.  I think from now
on I'll "reply all".  I didn't realize we were having mail delays...

On Tue, Jan 5, 2010 at 17:26, Tomasz bla Fortuna <address@hidden> wrote:
> Dnia Tue, 5 Jan 2010 00:08:15 -0600
> Hannes Beinert <address@hidden> napisał(a):
>
>> Tomasz,
>>
>> I noticed that you had a timestamp field for the last OOB channel use.
>>  Where is the passcode kept?  Or is the idea that the PAM module get
>> that passcode directly, and that it's stored in the process context?
>>
>> The latter assumes that one is able to wait at a passcode prompt until
>> the OOB channel actually manages to deliver the passcode.  That's
>> probably a decent bet, nowadays, I suppose.  But if that delay time
>> gets too large, it could be inconvenient.
>
> Two options:
> 1) We run ssh and otpasswd RESERVES us a passcode. Then it sends it via
> OOB and waits for reply. This works with my mobile network and free
> gateway. Should work with hardware sms sender (mobile connected to
> computer). Is generally most safe approach.

I agree that it's safe, but it requires that the passcode arrives
before the connection times out.  That is probably reasonable...  but
it may not be.

> 2) We ask system for passcode (via ssh, web or anything). This passcode
> we get via sms for example and we then log in to use it. This suffers
> DoS condition because passcode is not reserved attacker can fail to
> authenticate after we've requested passcode and use this passcode up.

Hmm.  So this scenario assumes that IF an oob has been requested (and
sent), that this will be the ONLY passcode that is accepted on the
next authentication attempt.  Yes, I can see the DoS you are
describing.

> timestamp field is used to prevent OOB DoS when attacker somehow causes
> system to send more OOB than should be accepted.

I'm not sure I understand.  Are you saying that this is a "throttle"
(a limit) on the number of oob passcodes that will be sent in a given
time?  I should check the code...

>> Another way to go about this is to use the login prompt (and/or a
>> website) to prompt the transmission of the passcode to the user.
>> Meanwhile, that passcode would be stuffed into the user state file
>> with the timestamp.  Then, next time a login happens, if it's within
>> the time window set by policy, the user would use that passcode to
>> authenticate.
>
> I doubt it's so easy. Say there's a place for one remembered oob.
> requesting next oob removes previously stored information making
> previous passcode unusable. Trying to authenticate after user requested
> OOB also suffers DoS problem. Hm.

First, we are agreed that only ONE oob (maximum) will be valid for any
user at a given time, right?  I can't see any reason why a user should
ever try to inventory more than one oob.  And second, it makes sense
that any user who uses oobs will have an spass, right?  Given this,
some thoughts:

(1) Every time an oob is sent, a timestamp is issued.  No new oob can
be issued before this oob is either used in an authentication, or an
*initial* time interval elapses (some interval set by policy).  This
prevents the second oob from overwriting the first oob for the length
of this time interval.  Then, the oob will expire completely after a
second time interval.  This creates an "oob authentication window".
Hmm.  However, I suppose that if the attacker attempts to authenticate
before the user, then as you say, the oob could be used up.

(2) What if in order to use an oob, one *must* use the spass to select
the fact that one is doing an oob authentication?  This would be along
the line of the OTPW prefix password authentication...  In this case,
the attacker would have to know the login password AND the spass in
order to consume the oob.

>> Just thinking aloud.
> Just replying aloud. ;-)
;-)

> SSH session can be 'held' for at least a minute on authentication
> screen as I've tested once.

Yeah...  but that's so implementation-dependent.  If a sysadmin has
cut down the amount of time that ssh will wait (LoginGraceTime), then
it could get tricky.  For example, if the user is choosing email
delivery of passcodes.

How about two modes of operation?

(1) You open an ssh session, use *that* session to get an oob sent to
you, then use *that* oob to authenticate.  This will work if the
connection is fast.

(2) If you can't do that, then use the web, or whatever, to get an oob
sent, and *then* open a session, in which case you have to use the
spass with the oob?

Hannes.