RE: Account Lockouts

From: David LeBlanc (
Date: 12/06/04

  • Next message: Michael Wojcik: "RE: Account Lockouts"
    Date: Mon, 6 Dec 2004 14:36:43 -0800
    To: "David A. Wheeler" <>, <>


    David A. Wheeler [] said:

    > Watch out for parallel logins, though.
       This can still mean that an attacker can always lock out
       everyone, but only during the duration of an attack;
       halt the attack & the lockouts cease quickly.

    That's something that goes back to my start in the security business - I
    was working for a small telephony provider, and they had their own
    calling cards. One thing we looked for as a problem scenario was
    multiple calls happening on the same calling card at once. If you see
    someone trying to parallelize attacks on a given user by coming from
    multiple addresses or sessions at once, you can then take action -
    either lock out the account for a while, or substantially increase the
    delay time.

    Another approach would be to force logins for a given account to
    serialize. So regardless of source IP, one failed attempt means you need
    to wait 10 seconds before trying again. Two failed attempts goes to 20
    seconds. A legitimate user who really has the password would be delayed,
    but not prevented from logging in. Obviously, the code needed to do this
    is a lot harder to write correctly than it is to suggest.

    That's an approach which has been used successfully with certain
    protocol problems, but it can be generalized to this - detect when
    you're under attack, and then change behavior in a way that inflicts
    more difficulty on attackers than legitimate users.

    The biggest thing is not to let the users pick poorly chosen passwords.
    That part takes some work, and you have to be prepared to give them
    understandable guidance about just why it was a bad password, and how to
    pick one that will pass your requirements. If a password won't fall to a
    direct dictionary attack, and is reasonably long (IMHO, 8 characters or
    more) and complex, then the attacker would need a very, very long time
    at 6 cracks/minute to get anywhere.

  • Next message: Michael Wojcik: "RE: Account Lockouts"

    Relevant Pages

    • Re: GPU (parallelization)-resilient pseudorandom function in PBKDF2
      ... the brute-force attack useless. ... more resources for the private key legitimate user) but the extra cost ... A delay in the KDF means C = D: if it's twice as expensive for the user, ... offline dictionary attacks with the use of PAKE (Password-Authenticated ...
    • Re: Hyper-Threading Considered Harmful
      ... In Colins case the attack is easily avoidable by not ... don't give out shells like candy. ... In the case of AES all you have to lock is the sbox tables. ...
    • Re: My Revised Ganking Policy
      ... I won't do anything unless they attack first (why would ... anyone attack someone up to 10 levels above them??). ... way for the horde to get there, unless summoned by a lock. ... Nope, he was coming from the Badlands, running north. ...
    • Re: My Revised Ganking Policy
      ... anyone attack someone up to 10 levels above them??). ... hordes, who were attacking a lock in southern Barrens. ... way for the horde to get there, unless summoned by a lock. ... "When you try to change a mans paradigm, you must keep in mind that he ...
    • Re: OT - locksets.
      ... Schlage is onwe of the better basic residential-grade lock mechansims. ... For basic business use the standard of reference for base-level security ... target of a WELL-PLANNED, carefully directed, attack. ...