Educause Security Discussion mailing list archives
Re: Account Lockout Policies
From: Graham Toal <gtoal () UTPA EDU>
Date: Fri, 14 Jul 2006 16:27:50 -0500
Specifically the attacker could know that if a response was not received within a few milliseconds, then the passphrase was not correct. He would then stop waiting for (ignore) the response to that login request and initiate a new login request. One solution to the two problems I listed above would be for the server to forbid a new attempt until the (delayed) failure message from the previous attempt was sent.
Another solution is that whatever the delay you apply may be, you apply it to a *successful* login as well as a failure, so that they can't disconnect early. The problem of pipelining requests like this to get around backoff periods has been known for a long time. In telnet-like logins the delay is useless because the caller can just make one request per session, and have several sessions in parallel. A solution to this might be to delay responses to a specific IP regardless of whether it is the same session or not, but this penalises callers from single-IP NAT sites. G
Current thread:
- Re: Account Lockout Policies, (continued)
- Re: Account Lockout Policies Valdis Kletnieks (Jul 11)
- Re: Account Lockout Policies Cheek, Leigh (Jul 11)
- Re: Account Lockout Policies Randy Marchany (Jul 11)
- Re: Account Lockout Policies Gary Flynn (Jul 11)
- Re: Account Lockout Policies Gary Dobbins (Jul 11)
- Re: Account Lockout Policies Valdis Kletnieks (Jul 11)
- Re: Account Lockout Policies Russell Fulton (Jul 12)
- Re: Account Lockout Policies jack suess (Jul 12)
- Re: Account Lockout Policies Gary Flynn (Jul 13)
- Re: Account Lockout Policies Jonny Sweeny (Jul 14)
- Re: Account Lockout Policies Graham Toal (Jul 14)