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

[Hannes Beinert]

On Tue, Jan 5, 2010 at 20:04, Tomasz bla Fortuna <address@hidden> wrote:
> Dnia Tue, 5 Jan 2010 19:51:14 -0600 Hannes Beinert <address@hidden> 
> napisał(a):
>
>> 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...
>
> It's supposed to be, not yet implemented fully.

Yeah, that's understood.  I'm just trying to understand the design.

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

Okay.  So how about three other "conditions" on oob use:
(1) Above
(2) Above
(3) An oob will have a minimum lifetime, specified by policy,
(4) An oob will have a maximum lifetime, specified by policy,
(5) An oob will expire when it used in any authentication (successful or not)

Do these conditions also make sense?

>> (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.
>
> Or just spamming the OOB channel. Problem is that with non-reserving
> approach sending OOBs will not increment the counter therefore we will
> send the same oob all the time. We'd have to add another counter or
> increment counter on oob request (which is not currently the case).

As far as spamming the oob channel -- I don't think we have any
control over that.  I think that if this is a concern, the user must
configure multiple oob channels, and choose them as appropriate to
deal with this.

One could implement a "recognition phrase" in the oob transmission
message.  Namely, the previous passcode that was used for successful
authentication could be sent along with the new oob to perhaps aid in
the recognition that this is the valid message.  Alternative, a
semi-static recognition phrase could be configured, too.  I don't know
if it would help much, but it would make it more difficult for the
attacker.

As far as re-sending the same oobs, you had mentioned in a previous
email that you were thinking of using a system-wide sequence key for
generating oobs.  I think this is a really clever idea, since the only
requirement for user-specific keys is because users need passcards.
If a passcard isn't needed, then just use a single key.  And, in this
case, there's no need to reserve the passcode.  Simply generate it,
send it, and advance the counter.  Either it's used, or not, but who
cares?  In this scenario, one would never send the same passcode.

The system-wide oob sequence key could be stored in the otpasswd.conf
file, although I think that a special user state file would be better.
 Use the same state file format you're using, and then there are two
cases: (1) DB=user, in which case I'd put a pseudo user-state file
into /etc/otpasswd, perhaps named something like
/etc/otpasswd/otpasswd.oob, and (2) DB=non-user, where I would use
some pseudo-user name, such as the username for the USER=xx parameter
in the conf file.

>> 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.
>
> This he can gather with keylogger easily. This makes it complicated for
> ANY attacker to perform attacks; reduces their count to few which would
> otherwise gain access to the system via keylogger. I wouldn't rely on
> spass to solve problem. But I guess there's no much options.

I agree that the spass should be used as little as possible, and
preferably at times which cannot fully be predicted by the attacker.

I also don't like the idea of having two passcodes valid at a given
time -- ie, the regular passcode sequence, plus any currently
unexpired oob.  That gives the attacker a *slightly* larger chance at
"getting it right".  Some type of disambiguation is needed.  Hmmm.

Just to be clear about the problem this is trying to address -- we're
trying to overcome a DoS by an attacker who is constantly trying to
authenticate thereby consuming passcodes before the user has a chance
to legitimately authenticate, right?

I suppose the first situation that needs to be discussed is the role
of the system password.  Two cases:

(1) If pam_unix is requisite.  Two subcases (:-):
(1a) pam_unix is requisite, and he knows the password, at which point
he can consume passcodes at will, thereby subjecting the user to a
DoS.  Since we don't have "dont-skip", this is a problem case.
(1b) pam_unix is requisite, he doesn't know the password.  This is not
a problem.

(2) If pam_unix is required, then the system password doesn't matter.
pam_otpasswd will be asked to authenticate, and it will consume *some*
passcode -- either the oob, or a regular key in the sequence.  This is
also a problem case.

To me, the crux of the problem is that pam_otpasswd must know which
"code sequence" to use -- either the regular sequence, or the oob
sequence -- and whichever sequence it chooses, it will consume the
current passcode.  One way to address this knowledge is, as I said
above, find a way to disambiguate *which* code sequence is being
chosen to authenticate.  Some extra piece of knowledge could be added
to the passcode entry for this purpose, and it should likewise be
"one-time".  It is suboptimal to choose the spass for this purpose,
because it has other capabilities, therefore more danger if this
password is compromised by a key logger.

What about these ideas:
(1) Every oob is generated at a specific known time.  Require that oob
entry be composed of two parts, such as a concatenation of  <msec %
10000><oob>.  If the first part isn't correct, then don't bother
validating the oob, and don't consume it.
(2) Send an OPIE-like recognition word to serve the same purpose.
(3) Make the oob much longer than a regular passcode, but use
"dont-skip" logic.  The oob would only, after all, be valid for a
specific window of time.

All three of these ideas leverage the same idea -- a second discrete
piece of information, a nonce, which would disambiguate not only the
fact that this is an oob authentication, but that you are the correct
user to whom the oob was sent.  Unless you have a better name for this
second chunk, how about calling it the one-time validator (OTV)?  :-)

I think that all of these approaches would solve the problem, and
would provide good security (probably just as good as with a regular
passcode sequence, since we would be dramatically increasing the
passcode-space).  I *think* that the only thing that would
differentiate these ideas is the user-friendliness.  Case (2) is
probably the most friendly.

Thoughts?

>> >> 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?
>
> Can be done I hope. Problem is with with getting this passcode with
> prompt-command as when we get prompt passcode is already reserved.

I do think that these are two distinct modes of operation,
conceptually, although they don't necessarily need to be different
from the user's perspective.  Ie, an OTV could always be used for OOB
passcodes, although in mode (1) it wouldn't be necessary.

> ... Also
> I'd like to note that email-OOB isn't very secure. It complicates
> attack, but doesn't solve problem. If mail is to be received on the
> possibly trojaned/keylogged workstation then it theoretically can be
> sniffed and used before we manage to do so.

You're absolutely right.  However, I was thinking that email gateways
are really common for SMS, etc.  Ultimately, there's no way we can be
sure that the user is really using a separate device to receive the
oobs.  I suppose requiring a cellphone number and directly pumping the
oob into a messaging server (or TAP, or SNPP, or whatever) would make
it far less likely...  To me, though, this is a matter of policy.  If
the admin wants to allow email oob channels, then so be it.
Personally, I would be likely to use an email-SMS gateway, and using
IM would also be handy.

Hannes.