Dropping the ball on Kevin, BIG TIME!!!
Looks like our friend knows a thing or two about Brute Force Attackshttp://pdos.csail.mit.edu/pipermail/asrg/2003-July/000340.html
[ASRG] [email@example.com: Re: Remembering history passwords may be bad, but they are getting worse]
Simson L. Garfinkel slg at ex.com
Tue Jul 29 22:05:29 EDT 2003
Previous message: [ASRG] [firstname.lastname@example.org: Re: Remembering history passwords may be bad, but they are getting worse]
Next message: [ASRG] [email@example.com: Re: Remembering history passwords may be bad, but they are getting worse]
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
What would be interesting to me would be to know who the attackers are.
I mean, are they other pornographers, users who want to get free stuff,
or are they anti-pornographer crusaders?
On Monday, July 28, 2003, at 12:33 PM, David G. Andersen wrote:
> Once again, the porn industry is at the forefront of Internet
> research. ;-) (Kind of a cool read)
> ----- Forwarded message from Kevin Day <toasty at dragondata.com> -----
> Date: Mon, 28 Jul 2003 00:39:35 -0500
> From: Kevin Day <toasty at dragondata.com>
> Subject: Re: Remembering history passwords may be bad, but they are
> getting worse
> To: Sean Donelan <sean at donelan.com>
> Cc: nanog at merit.edu
> X-Sender: toasty at mail.dragondata.com
> X-Virus-Scanned: by amavisd-new
>> The problem is fewer and fewer modern systems implement the other
>> recommendations. So password lifetime has become the primary
>> How many systems notify the user
>> - the date and time of user's last login
>> - the location of the user at the last login
>> - unsuccessfull login attempts since last successful login
>> How many web systems control the rate of login attempts
>> - by source
>> - by userid
>> How many web systems notify anyone or block the account after N
>> unsuccessful login attempts either temporarily or permanently
> I run one of the larger adult websites, that has a reputation for being
> very difficult to acquire passwords for.
> The kind of attacks we see now aren't solved by any of the above. We
> throttled the number of login attempts per IP, then the attackers
> to using proxy servers. Tens of thousands of them at once. Our
> database of
> IP addresses that have had more than 100 bad login attempts is now
> 100,000. (Most of which are all now banned completely).
> We also tried put rate limiting on login attemps by username. This
> any idiot to lock any of our legit customers out of the system whenever
> they want, providing an easy denial of service, so this was scrapped
> The attacks we see now are... well orchestrated. 10-50,000 proxy
> all making login attempts at once, rather slowly. 10-50 login attempts
> second, each from a different proxy. Still slow enough per IP that it
> doesn't hit our threshold for how many bad logins per IP per hour we
> but enough attempts that just by trying seemingly random
> combinations they get a couple of successes a day. We've also seen
> trying what appear to be known good username/password combos that were
> presumably acquired from other sites that were compromised in some way.
> We keep detailed histories of all the login attempts per IP, and can
> eventually weed out the exploited proxies from actual users, but this
> an incredible amount of our time, CPU time and database storage just to
> manage. A few weeks ago, after we tightened our login attempt limits,
> whoever is doing this decided to point all the proxies to a public URL
> was very database intensive, and requested it over and over
> again(apparently to get revenge/in frustration), killing our database
> server for several hours until I figured out what was going on.
> We tried putting up something that was displayed to users showing their
> last login time and IP, in hopes that some would notice their account
> used by others. Many ISP's force users to go through a proxy server,
> usually without their knowledge. We'd report the IP address that we saw
> (the proxy server) which would freak out many users because it didn't
> their system's IP. The login time is apparently meaningless to most
> who didn't seem to keep track of when their last login in.
> We do have our tricks to detect when an account has been compromised,
> they're not 100% accurate, so it usually comes down to having to wait
> our friendly hacker and his 500 closest buddies are all sharing the
> We're taking steps to make brute force attacks like that impossible
> random passwords, etc) but we've found that many users won't tolerate
> being able to choose their own password. If forced into it, they forget
> their passwords very easily and the support costs from dealing with
> password recovery are generally higher than passwords leaking out.
> While the recommendations you listed are probably worthwhile to stop
> attacks, they're not going to stop people determined enough to get into
> SOME account if they're not picky on which one.
> -- Kevin
> ----- End forwarded message -----
> work: dga at lcs.mit.edu me: dga at pobox.com
> MIT Laboratory for Computer Science
> I do not accept unsolicited commercial email. Do not spam me.
> ASRG mailing list
> ASRG at amsterdam.lcs.mit.edu