North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Kevin Day
  • Date: Mon Jul 28 01:41:48 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