| |
In lugnet.people, Kevin Loch writes:
> > BTW, what is cookie/ip pair?
>
> The BrickShelf uses the cookie returned *and* the ip address that the cookie
> was issued to for reauthenticate login. Nobody has complained about loosing
> login yet via multiple proxies (i.e. aol).
But doesn't that make somebody have to log in again if they use *any* kind of
non-static-IP connection -- i.e., a typical dial-up or DHCP connection -- and
not limited only to shared proxy servers? If they're on a typical ISP dial-up
PPP connection and hang up the phone and dial back in ten minutes later, do
they have to log in again to make more changes?
> Also, cookies can be made
> *much* more difficult than typical passwords (BrickShelf uses 64 bytes).
>
> If successful login takes 10ms, and failiures delay by 2 seconds, I know
> if I don't receive a response within 100ms I can try again.
I don't see how that's an effective deterrant.
If successful login takes 10ms, then a single attacking client process with
one child process that it kills after 10-100 ms could make, say, 10 to 20
attempts per second.
If successful logins are delayed by 2 seconds, why can't your client fork
20 copies of itself and try a whole bunch of pw's in parallel? If the server
isn't mutexing on the IP address, you'll know within a few seconds if any
of those worked, with comparable overall throughput in attemps per second to
the single-process attack.
Now, if a server mutexes on the IP address and delays all client processes
connected to an attacking IP address upon login failure, then delaying upon
successful login is moot, because attacks can't be sped up. So in either
case, why bother delaying upon success? Isn't the important thing is to have
a solid way to limit the overall throughput of failed attempts?
--Todd
|
|
Message is in Reply To:
113 Messages in This Thread:
(Inline display suppressed due to large size. Click Dots below to view.)
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
