RE: const time authentication in bozohttpd

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

Here's how it's typically done.

Choose a time (say one second) (call this delta_t).  Get the system clock
before you start authentication (call this t_mark). After any failure on the
authentication path, delay responding until t_now >=  t_mark+delta_t.  (The
overflow-safe way to compute this (t_now - t_mark >= delta_t).   

You can delay by CPU spins, or by using one of the apis that let you yield
the CPU.  If you're spinning, and 1-second granularity is acceptable, you
can just use the time(3) function, as long as delta is 2 or greater.  (I
wouldn't use a delta of one with any time-dleay algorithm because you're
generally only guaranteed that the delay will be in the range (n-1, n)
units.)

Delaying the response to an authentication failure also slows down some
brute-force attacks -- those which don't try to do things in parallel with
multiple connections.

Best regards,
--Terry


> -----Original Message-----
> From: tech-security-owner%NetBSD.org@localhost [mailto:tech-security-
> owner%NetBSD.org@localhost] On Behalf Of shm
> Sent: Wednesday, June 25, 2014 10:10
> To: Terry Moore
> Cc: tech-security%netbsd.org@localhost; tech-userlevel%netbsd.org@localhost
> Subject: Re: const time authentication in bozohttpd
> 
> On Wed, Jun 25, 2014 at 07:02:09AM -0500, Terry Moore wrote:
> > Perhaps this is a silly comment; but wouldn't it be easier to simply
time
> > stamp the incoming request, and then spin for any authentication failure
> > until a suitable fixed time has elapsed after the inbound arrival? Or
are
> > you worried about local cache-interference attacks as well?
> 
> It might be a solution, but I don't see any reasonable implementation,
i.e.
> it would be hard to guess how long the code will run. I'm not worried
about
> local cache-interference, I want to countermeasure attackers from the
> remote.
> 
>  Kind Regards,
>  shm@