assurance - Re: [Assurance] Password Strength Requirements
Subject: Assurance
List archive
- From: "Joe St Sauver" <>
- To:
- Subject: Re: [Assurance] Password Strength Requirements
- Date: Wed, 8 Aug 2012 15:33:31 -0700 (PDT)
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)
- Re: [Assurance] Password Strength Requirements, (continued)
- Re: [Assurance] Password Strength Requirements, Joe St Sauver, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Cantor, Scott, 08/08/2012
- Re: [Assurance] Password Strength Requirements, David Bantz, 08/08/2012
- [Assurance] Re: Password Strength Requirements, Jon Miner, 08/08/2012
- Re: [Assurance] Re: Password Strength Requirements, Stefan Wahe, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Cantor, Scott, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Joe St Sauver, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Cantor, Scott, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Brendan Bellina, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Cantor, Scott, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Brendan Bellina, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Cantor, Scott, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Joe St Sauver, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Joe St Sauver, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Cantor, Scott, 08/08/2012
- Re: [Assurance] Password Strength Requirements, Joe St Sauver, 08/08/2012
Archive powered by MHonArc 2.6.16.