assurance - Re: [Assurance] Counting Failed Logins Update
Subject: Assurance
List archive
- From: "Joe St Sauver" <>
- To:
- Subject: Re: [Assurance] Counting Failed Logins Update
- Date: Fri, 21 Jun 2013 14:01:27 -0700 (PDT)
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
- [Assurance] Counting Failed Logins Update, Benn Oshrin, 06/21/2013
- <Possible follow-up(s)>
- Re: [Assurance] Counting Failed Logins Update, Joe St Sauver, 06/21/2013
- Re: [Assurance] Counting Failed Logins Update, Brendan Bellina, 06/25/2013
- Re: [Assurance] Counting Failed Logins Update, Cantor, Scott, 06/25/2013
- RE: [Assurance] Counting Failed Logins Update, Capehart,Jeffrey D, 06/25/2013
- Re: [Assurance] Counting Failed Logins Update, David Walker, 06/25/2013
- Re: [Assurance] Counting Failed Logins Update, Benn Oshrin, 06/26/2013
- Re: [Assurance] Counting Failed Logins Update, Brendan Bellina, 06/25/2013
- Re: [Assurance] Counting Failed Logins Update, Joe St Sauver, 06/25/2013
- Re: [Assurance] Counting Failed Logins Update, Joe St Sauver, 06/25/2013
- Re: [Assurance] Counting Failed Logins Update, Cantor, Scott, 06/25/2013
Archive powered by MHonArc 2.6.16.