Re: Account Lockout Policies

[Jonny Sweeny <jsweeny () IU EDU>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> -----Original Message-----
> From: Gary Dobbins [mailto:dobbins () ND EDU]
>
> Instead of hard lockout, consider having the authentication service
> merely add an increasing delay to successive negative responses
> (and no delay to the final positive response). This slows
> brute-force guessers to a crawl, while not seriously impacting the
> legitimate user who simply needs one-more-chance to remember their
> new password.

I have long wondered why a similar solution was not more common.  But
I imagine that it would have to be a solution that Microsoft would
implement on the way the DC's handle authentications and likely isn't
a registry key you and I can tweak today.

You'd have to be careful how it was implemented though, as you
wouldn't want to allow a new type of DoS attack.  Your method
described above could allow a DoS on the Domain Controller(s) if it
were storing all the attempts in memory and waiting to send a
response.  Attackers could send hundreds of thousands of login
attempts and the server would have to remember each of them and wait
to send the response.  This could eventually cause the server to roll
over.

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.

My envisioned solution has always been that the server send a certain
"bad password" failure code and then a different "try again later"
failure code (without even checking your username/passphrase) until
the configured time has elapsed.  I have always envisioned an
increasing delay between attempts (1 second, 2, 4, 8, 16, 32...), and
the same delays being seen in logins at the terminal and remote
logins (though perhaps configurable in Group Policy).

I am amazed that I've not seen solutions like this in place on any
system with the amount of SSH brute-forcing.

Am I crazy?  Thoughts?

~Jonny Sweeny, Senior Security Engineer, GSEC, GCWN, SSP-CNSA
Office of the VP for Information Technology, Indiana University
PGP key & S/MIME cert: https://itso.iu.edu/Jonny_Sweeny


-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.4 (Build 4042)

iQA/AwUBRLfiu5J3HTSZuWnoEQKeJQCdEaR9r3PmD3o6ykHt3m/Pkl1uWAoAoPLf
Dn7kSSmqPP/dvVW2yKa59tR1
=NQtd
-----END PGP SIGNATURE-----