Re: Remembering history passwords may be bad, but they are getting worse
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
Kevin Day wrote:
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.
But, in turn, there are at least two distinct aims here; 1. Authorised access; people want free porn. 2. DoS; people object (either "on principal" or by competitors) to the service you provide, so they want to deny access to others or make it too expensive to run. Defending against one usually makes the other easier :( Peter
Kevin Day wrote:
I run one of the larger adult websites, that has a reputation for being very difficult to acquire passwords for.
One of the more interesting "passive" ways to manage a site like this is to do something similar to what Streamload does (or did, I haven't tried it lately). I don't know if this is useful for other web services, but for most non-shared accounts, there should be a limit of how many unique IP addresses in a set time period can access a given account. The limit shouldn't be one, because with dynamic IPs, and people having work & home computers, but for example 5 unique IPs per 24 hours would catch a shared password within a day or less. Another limit to consider is one session per username at a time, so if a user is "logged in" and another authenication attempt is made from a different IP, it either terminates the first user's session or refuses login. Back in the late 80s/early 90s we had a service in my area called "POPNET" that was a multi-user BBS. They were a pay service, and if an account logged on twice they would lock the account for 24 hours. It stopped password sharing real quick :) I personally would not object to a secureID or USB RSA dongle for online banking/etc, but I can see a problem with "too many standards" where you would have a secureID or key dongle for every different credit card and bank account. What would be nice to see is a trusted third party (insured against loss like a Bank is) that would have a single secureid issued that would be key for any number of different financial services. This is different than something like Microsoft's "Passport" initiative in that it's a> secureid based, and b> would be maintains by a trusted company, and c> would be cross platform. -Scott
If you would like to learn more about the strengths and weaknesses of various authentication methods, I highly recommend the book Authentication: From Passwords to Public Keys by Richard E. Smith ISBN: 0201615991
participants (4)
-
Kevin Day
-
Peter Galbavy
-
Scott Call
-
Sean Donelan