Assurance

["Joe St Sauver" <>]

Benn asked:

#- Is anyone (considering) maintaining a simple failed authentication
#counter per-password, and expiring the password once the counter reaches
#the limit permitted by the complexity for the level (Bronze/Silver) of
#interest? (ie: no lockout, no scheduled expiration)

My concern with employing that approach would be that it could easily be
exploited for a trivial denial of service attack: strobe all discernable
accounts with sufficient attempts to trigger expiration, then watch
a synchronized flood of users who can't successfully change their old
(now expired) passwords deluge your help desk/account clerk for manual
assistance. (Yes, I know that users should be able to readily change 
their passwords, but as a practical matter, that may be an unfounded
expectation.)

Forced password changes is particularly tricky if password changes cannot
be accomplished "in-line." That is, in the old days when it was all just
shell access to time sharing hosts, an expired password could be handled
in-line just by dumping the user into the password changing facility
directly. However, once users begin authenticating via POP and IMAP clients,
and VPN clients, and every other application under the sun, it gets a lot
harder to cleanly force them to a reset facility, and of course, phishing
makes advising them by email difficult, and the list of complications goes
on...

#- Where password lockout is being used (for n amount of time after m
#failed attempts, but then unlocking the password without reset unless it
#has expired), what "slider" settings are you using/planning to use
#compared to what you previously used/currently use? How, if at all, are
#you (planning on) handling DOS risk?

I've long advocated for adopting this sort of OpenVMS-like login 
hardening scheme. In a nuthshell:

-- accept up to N failed auth attempts (where N is often 3)

-- once you've seen more than N failures, ignore subsequent attempts FROM 
   THAT IP, FOR THAT ACCOUNT, even if the correct password is subsequently
   provided, until configurable time delta has cooked down with no further 
   attempts (delta might be 15 or 20 minutes)

-- provide no indication that the account is in temporary lockout while
   this protective hold down process is occuring

-- if additional attempts occur before delta time has expired, reset the 
   timer to the original delta value, and resume the hold down process

Downsides to this approach:

-- if you have an application (like a POP or IMAP client) that is set to
   routinely poll a server, and it has a saved (wrong) password, that
   activity can leave a user locked out perpetually until they tell the
   dang client to quit trying to login with the wrong saved password

-- because you're not "coaching" the person entering the wrong password,
   the user can become quite confused in some scenarios (e.g., user thinks
   they remember their password, tries a few possibilities, then looks it
   up in their online password safe or on their slip of paper in their 
   purse or wallet, only to find out that even what's ABSOLUTELY their 
   right username/password "still" won't work)

-- an internal attacker in a situation where NAT/PAT is used can still
   DOS folks (e.g., if their IP is the same as the legitimate user's IP
   from the perspective of an external attacker)

-- it incents what might be called "breadth-wise" attacks: test each of
   a gazillion accounts with one possible passwords, then loop back 
   around and test each of those accounts with the next possible 
   password, thereby ensuring that the rate of tests (and failures)
   per account is kept below the threshold

Regards,

Joe