Assurance

["Joe St Sauver" <>]

#>My concern with employing that approach would be that it could easily be
#>exploited for a trivial denial of service attack:
#
#I've gotten exactly nowhere arguing that this is a problem. That's
#somewhat reinforced by the fact that we've been doing it here for a while
#with no problems. Are there actual examples of this happening?

Are you talking about examples where passwords needed to be changed in
bulk? If so, consider this public example:

   
www.authoritydomains.com/blogs/authority-domains/hackers-trigger-password-resets.php

   "An attack on Gawker, which runs one of the world's most popular blog
   networks, was carried out over the weekend by an organization calling
   itself Gnosis. Millions of web users including on Yahoo, Twitter and 
   Linked in were asked to reset their passwords as concerns spread over a 
   mahjor hacking attack." [December 15th, 2010]

Even then, however, note the careful use of the word "asked" rather than
"forced" to change their passwords...

If you *require* users to change their passwords, you can easily run into
situations where there simply isn't the required capacity to handle them
all in parallel.

For example, following an incident here at UO many years ago, we discovered 
the hard way that forcing all users to do a mandatory password change 
exceeded the capacity of our password-changing infrastructure at that time -- 
it was one of the reasons why me rearchitected and beefed up how we handled 
that specific task, in fact...

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.

Now repeat that process: I predict that by the 3rd|4th|5th|nth time you make
the bigshot change his or her password as a result of password probes, the 
policy will be junked (or at least you'll need to make a "white list" for 
the bigshots whose passwords must not be expired, no matter what)...

Of course, the irony is that those sort of bigshots may be precisely the sort
of people who most need strong auth...

#The perspective here seems to be that the risk is low and the standard
#network scans we do detecting unusual activity would slam down fast enough.

Every environment will be different, and I don't mean to imply that any
one answer is right for every school. Whatever works for a given site is
terrific, from my POV. I'm just suggesting that some policies can have
subtle but potent side effects that bear consideration.

Regards,

Joe