Assurance

["Joe St Sauver" <>]

Hi,

#>Are you talking about examples where passwords needed to be changed in
#>bulk? If so, consider this public example:
#
#I'm talking about a mass DOS attack using the lockout as the vector.

Intentional DDoS? Or accidental DDoS? If the later, Conficker probably 
qualifies. See, for example:

   "Rethinking Thresholds for Account Lockouts"
   
http://lukenotricks.blogspot.com/2009/05/rethinking-thresholds-for-account.html

   I quote in part:

      "One of my colleagues informed me that Conficker caused quite a few
      password lockout [sic] of administrator accounts at his company. The
      worm used a quick password-guessing attack on privileged accounts.
      Unless an account had no lockout policy set, then such accounts would
      be either compromised or locked out by Conficker."

Note that despite the best efforts of the Conficker Working Group, Conficker
remains a PITA at at least some sites.

#>Moreover, if you're maliciously inclined, it's easy enough to demonstrate
#>the futility of the "if brute forced, trigger password required password
#>reset" -- pick a highly influential person at your site (President, VP,
#>Provost, CIO, highest-funded campus researcher, talented-but-grumpy DBA,
#>or whatever), then trigger the brute force equals must change password
#>rule. First time it happens, if you're lucky, they'll grumble but they'll
#>hopefull go along with picking a new password.
#
#Yeah, but. I'd get caught. 

Why's that? 

Hypothetically, a remote attacker can use one of the gazillion open proxy 
servers available on the Internet to attack a given user (some open proxies 
are listed at http://www.publicproxyservers.com/proxy/list_country1.html -- 
please note that I make no assertion that those proxy servers are 
intentionally open, nor that they are trustworthy/secure for sensitive 
traffic, nor do I meant to imply that anyone should actually engage in 
password lockout attacks). 

Anyhow, assuming they are using those proxies, their login attempts to your 
University President's account (or the account of the 
grumpy-but-talented-DBA, 
or whatever) then traces back to the proxy server, not to the d00d's actual 
workstation. As such, their chances of getting caught range from slim to none.
In many cases, the proxy server will turn out to be located somewhere
inconvenient, such as one of the Central Asian 'stans, or some equally 
inhospitable/inaccessible place.

Of course, since proxy chaining is also possible, a careful user might have 
additional proxies also in use, perhaps chaining through proxies in Germany 
or Peru or Thailand or whatever. As the number of proxies in the chain
increases, and the number of jurisdictions increases, your ability to 
successfully backtrack that traffic drops quickly to become effectively nil.

"But Joe!," some might say, "We firewall 'all' remote access! A user would 
need to be internal to be able to try to do brute force login attacks! Then
we will be able to track them!"

Maybe, but I've got a sneaking suspicion that most sites have at least
*some* authenticated services that are publicly exposed. Maybe it's POP/IMAP, 
or SMTP submit, or a web email interface. As long as those logins "count" 
toward account lockout, and they're d00d-accessible from Uruguay or Poland
or wherever, you've got a problem (and naturally, if they're remotely
accessible and DON'T count toward triggering defenses, they can then be
used to brute force the account -- danged if you do, danged if you don't,
if lockout's your main magic bullet).

#Again, you're proposing theoretical technical/wonky attacks that mean
#nothing to the non-techies here. 

Not theoretical attacks. Very, very basic script kiddy-class attacks,
including attacks that don't even require any special tools (example:
if you have an exposed IMAP client interface that can trigger the 
lockouts, and I know the username of the user that I want to DDoS, I 
just configure Thunderbird to try to login to the targeted user's 
account every minute with an intentionally wrong password, optionally 
doing so through a proxy server to hinder backtracking.)

#They laugh at it.

I always am happy when folks have a good sense of humor. :-) I just hope that
they retain that sense of humor if/when they get bitten by unexpected side 
effects of policies that they've decided to adopt :-)

Regards,

Joe

P.S. Oh yes, just in case folks think that the self-unblocking IP-based block
approach is exotic and unique to OpenVMS, note that it also shows up 
(modulo a somewhat different implementation) in some Juniper gear, e.g., 
see "What is this SA security Lockout Mechanism and how does it work?"
http://kb.juniper.net/InfoCenter/index?page=content&id=KB13515&cat=SSL_VPN&actp=LIST
(e.g., in their case, users *are* told "IP address is blocked" and the block
is for *any* login from the blocked address, not just for a particular 
targeted user, but the fundamental are otherwise the same)