tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
RE: const time authentication in bozohttpd
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@
Home |
Main Index |
Thread Index |
Old Index