Assurance

[Brendan Bellina <>]

Joe,

I think these DOS points are well-taken and have raised them myself with 
auditors and such who don't seem to take this risk seriously.  Since 
University account logins are usually obvious and systems are public we are 
at greater risk than corporations where account logins are not obvious and 
systems are not public.

One way to thwart brute force attacks without adversely affecting account 
owners is to exponentially slow down the responses to bad password attempts, 
rather than all password attempts. There is no need to lock out the account 
in this case.  This also prevents the accidental lockouts that would be 
caused by the "hyperactive email checkers" you refer to.

Regards,

Brendan Bellina
USC ITS IdM Mgr

On Jun 21, 2013, at 2:01 PM, Joe St Sauver 
<>
 wrote:

> Hi,
> 
> Benn commented:
> 
> #The Counting Failed Logins working group met yesterday and had a fairly 
> #productive conversation. Some notes are available at
> #
> #  https://spaces.internet2.edu/x/FRFOAg
> 
> I know that implicitly this work is motivated by 800-63-2's requirements
> that limit failed authentication attempts to 100 or fewer per 30 day period,
> e.g., see 8.2.3 in 
> http://csrc.nist.gov/publications/drafts/800-63-2/sp800_63_2_draft.pdf
> 
> My concern, however, is that the details of the specified mechanisms don't
> really make sense to me, as defined there. 
> 
> Why calendar months, for example? Why not a rolling window, instead? 
> (I really dislike magic dates, and I have a mental image of bad guys sitting
> there poised, ready to just go crazy on the 1st of the month, each and every
> month :-( )
> 
> And if you block an account after 50 or 75 or 100 failed login attempts, 
> you're giving attackers a terrific denial of service attack modality 
> ("Gave me a bad grade on my final, did you, professor? I'll show YOU!!!
> [intentionally failed login] [intentionally failed login] 
> [intentionally failed login]... "LOGIN DISALLOWED"... [evil smile from
> disgruntled undergraduate])
> 
> Even if you're an "easy grader" and not being specifically targeted,
> simple background radiation/random login attempts from any or all of 
> the IPs at www.dragonresearchgroup.org/insight/sshpwauth.txt could 
> pretty quickly put ALL your users into a too-many-failed-auth attempts/
> blocked state (and having ALL you users get blocked that way is my
> personal *definition* of "having a s*cky day..." I'm afraid)
> 
> In the old days when I was doing user support, I can also remember seeing 
> users from time to time who'd have saved their POP or IMAP password in 
> Thunderbird (or whatever), only to change/reset their password globally, 
> while forgetting to change it in Thunderbird. 
> 
> If that person was one of those "hyperactive email checkers" we all know
> (e.g., set to automatically check for new email every five minutes) it 
> wouldn't take long for that user to blow through fifty or 100 login 
> attempts, all with the same wrong/former password, all from the same IP. :-(
> 
> There's also no discussion of how the failed logins could be "reset" --
> does this imply that a user could potentially be "done" using his or
> her username and password (even with the RIGHT password), for up to a 
> *month* after hitting a hundred login failures on the 1st of the month?
> 
> Bottom line, I just don't think that's practical. This has bothered me for 
> a 
> long time, looking at that document. 
> 
> Even doing something like exponential backoff is equally problematic from
> my POV, it's just a matter of scale (don't know about you, but if it takes 
> an hour for me to get a login/password prompt, that's effectively no 
> different than being blocked from logging in outright)
> 
> And then they dredge up CAPTCHAs. Those things have gotten to the point 
> where the automated CAPTCHA solvers are better at solving those things 
> than we mere humans, and they can be a real problem for disabled individuals
> unless accomodation is carefully provided, but in a way that can't then
> be maliciously exploited. 
> 
> [BTW, as a former math major, I rather like the "qualifying questions" 
> used at http://random.irb.hr/signup.php but I suspect that I may be 
> in the minority when it comes to my enthusiasm for their approach]
> 
> White listed IPs? Well, I suppose, however as a person who travels, I just
> KNOW that the time I'm going to suffer a brute force attack will be when 
> I'm in Baltimore or Batavia or Bratislava, and the IP that I'll be on there
> won't be an IP that's on my pre-populated white list.
> 
> Even in more mundane circumstances, it would seem like dynamic IP addresses 
> would be a problem. (I was on x.y.z.48 and x.y.z.107 previously from the
> DHCP pool, but this time, luck of the draw, I got x.y.z.72, instead, and 
> *that* IP isn't whitelisted, sigh!)
> 
> And of course, section 8.2.3 also punts on breadth-first attacks (e.g., 
> attacks against a large number of users rather than just hammering on 
> one user sequentially). 
> 
> I'm really curious what folks thoughts are around these issues, which 
> frankly
> seem pretty severe to me.
> 
> Thanks,
> 
> Joe
>