Remembering history passwords may be bad, but they are getting worse

Kevin Day toasty at dragondata.com
Mon Jul 28 05:39:35 UTC 2003



>The problem is fewer and fewer modern systems implement the other
>recommendations.  So password lifetime has become the primary protection
>factor.
>
>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

Sean:

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 switched 
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 around 
100,000. (Most of which are all now banned completely).

We also tried put rate limiting on login attemps by username. This allowed 
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 pretty 
quickly.

The attacks we see now are... well orchestrated. 10-50,000 proxy servers 
all making login attempts at once, rather slowly. 10-50 login attempts per 
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 allow, 
but enough attempts that just by trying seemingly random username/password 
combinations they get a couple of successes a day. We've also seen people 
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 takes 
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 that 
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 being 
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 match 
their system's IP. The login time is apparently meaningless to most users, 
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, but 
they're not 100% accurate, so it usually comes down to having to wait until 
our friendly hacker and his 500 closest buddies are all sharing the account.

We're taking steps to make brute force attacks like that impossible (forced 
random passwords, etc) but we've found that many users won't tolerate not 
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 some 
attacks, they're not going to stop people determined enough to get into 
SOME account if they're not picky on which one.

-- Kevin






More information about the NANOG mailing list