RE: const time authentication in bozohttpd

["Terry Moore" <tmm%mcci.com@localhost>]

[Apologies for using wrong message-quoting style. Resending for consistency]

Lewis Muir wrote:
> How do you choose delta_t?  Don't you have to be sure that delta_t
> is always greater than or equal to the time needed to authenticate?
> (Otherwise the times for a successful authentication and an unsuccessful
> authentication could differ thereby leaking information, right?)  How
> can you choose delta_t in a portable way?
> 
> I thought the way authentication is typically done is to be sure you
> do the same amount of work for both a successful authentication and an
> unsuccessful authentication.  Then you don't need to choose a delta_t.
> Authentication takes however long it takes, but the key property is that
> it takes the same amount of time regardless of whether it is successful
> or unsuccessful.

Well, if authentication succeeds, then the user is in, and has successfully
guessed a login and password (and it ostensibly an "authorized user"). 

The problem I thought the patch was addressing is that there are (at least)
two response paths.

1) Remote system failed quickly -- the username is invalid
2) Remote system failed slowly -- the user name is valid, but the password
is invalid.  

If pattern 2 is observed, you've successfully guessed a name, and you can
switch to guessing passwords (the search space is much reduced -- and
knowledge of a valid username itself may have value for chained attacks,
perhaps on related systems or subsystems, or even for phishing or other
social engineering attacks).

Of course, I'm making an assumption, because this wasn't explicitly stated
in the original mail. But that looks like a threat to me. This is analogous
to returning a different error message based on whether the username is
invalid, as opposed to if the username is valid but the password is invalid.
That's been known to be a bad idea for at least 30 years.

By delaying in the "non-authenticated case", you can deny the adversary the
knowledge of whether it's case 1 or case 2.

The delay time can be any time you like, as long as the minimum delay is
greater than the longer of path (1) and path (2).  You are going to disclose
the fact that user+password are invalid, in any case; but you should not
disclose more info than that.

Randomizing the delay (as mind@ suggested) will disguise the algorithm
you're using to hide the info, but the basic idea is to hide the info. I'm
not sure what else randomizing the delay will add (defense-wise) but I
imagine that I'm overlooking something.

It's also possible that I've totally misunderstood the original message! But
certainly, it's a bad idea to disclose whether you took path (1) or path (2)

Best regards,
--Terry