5 ms·

If the lockout is based on IP, there's a very high chance I can hide this from users because there's a very high chance that the nuisance is not coming from the

by timf 18y ago

If the lockout is based on IP, there's a very high chance I can hide this from users because there's a very high chance that the nuisance is not coming from the IP the user is logging in with. If my app starts getting attacked with password guessing scripts every day with correct account usernames, the users involved would need to be constantly doing this email based reset scheme. Personally, if this happened to me every time I logged in and there was an alternative to the service, I would take my business elsewhere...

tptacek 18y ago
I have zero faith in IP-based login reputation. Within the next couple years, the Internet will have a constant ambient stream of dictionary attempts on every web app that anybody knows about; that attack tool is very easy to write, and has a high payout (every Last.fm password is 60% likely to yield a gmail or ymail account). The dumbest attackers on the Internet are already smart enough to spread attacks over hundreds of IP addresses. The sites that are going to get targeted are the ones that don't do lockout. The ones that do will be worthless, except to get your bots killed. What are you really accomplishing by trying to make this seamless backoff system?
- timf 18y ago
  What does reputation have to do with anything? I'm not saying the lockout would be based on an IP database but rather the # of attempts would be scoped by the IP address it was originating from. At some point you could completely lock out attempts from that IP. Sorry if that was unclear. This means that there in almost all cases the IP used by the bona fide customer would not be in locked out mode or in exponentially backing off mode yet. I understand relying on different IPs is not going to work 100% of the time, spoofing and NATs etc. are a (small) problem in this scheme. In such cases, the "locked out" message will be displayed and the bona fide user will get his email anyhow. (I guess if the attacker was just trying to be annoying to someone, he could hit the 'locked out' button over and over again, is that the point you are trying to make?) What I am saying is that I do not want the user to have to bother with resetting their password until the last moment. The fact that this is not a "bulletproof" solution is not an issue. Getting things down to much less likely is a win in this case because it means the customer's experience has been enhanced (or rather, has not been un-enhanced). "The sites that are going to get targeted are the ones that don't do lockout. The ones that do will be worthless, except to get your bots killed." I don't get the reasoning here. I want a system that both discourages getting specifically targetted like you are saying -- but also one that has a contingency plan if there is an attack. What we seem to be disagreeing about is the contents of that contingency plan? You want a simple one and I want one that will try to avoid the customer needing to even know there was a problem if possible.
  - tptacek 18y ago
    "Reputation" is what the banks call this same solution, although it's just as silly there. My reasoning is, your solution is weak, and my solution isn't. Most user accounts are rarely or never used. IP based backoff is a speed bump for a coordinated attack against those accounts. Lockout completely stops it. And lockout is much easier to implement, which was my original point: people are wasting too much time thinking about this problem, and coming up with weird results.
    - timf 18y ago
      "IP based backoff is a speed bump" Exactly what I want from it. Speed bumps solve problems. Locking your car doors solves a problem. Neither guarantee anything but both have real effects which make people's lives better. That is, there can be another "N" here where the account gets shut down completely. If it ends up happening against one account from more than, say, 50 different IPs then shut it down and resort to inconveniencing the real user. Let's say 8 tries * 50 IPs, 400 is the new N where total cutoff happens. Too high? This makes it more likely that the bona fide customer won't be bothered by stupid script kiddies.
- mseebach 18y ago
  Make it reverse. Give known IP addresses a better reputation that unknown. Consider four zones: 1: the last three IP addresses the user has used; 2: any IP address the user has used more than 5 times; 3: any visit that has a valid "I've been logged in as user NN" cookie (given with expiry:never on every login); and 4: everything else. Lockouts are per zone. Chances are that your average automated attacker is always in zone 4, and that your legitimate user is always in zones 1-3, and that they'll never bother each other. You can then make a policy that's three tries and you're out for three hours, unless you verify your e-mail address. 24 tries a day should be low enough that dictionary attacks are infeasible.

by timf 18y ago

tptacek 18y ago

I have zero faith in IP-based login reputation. Within the next couple years, the Internet will have a constant ambient stream of dictionary attempts on every web app that anybody knows about; that attack tool is very easy to write, and has a high payout (every Last.fm password is 60% likely to yield a gmail or ymail account). The dumbest attackers on the Internet are already smart enough to spread attacks over hundreds of IP addresses. The sites that are going to get targeted are the ones that don't do lockout. The ones that do will be worthless, except to get your bots killed. What are you really accomplishing by trying to make this seamless backoff system?

timf 18y ago
What does reputation have to do with anything? I'm not saying the lockout would be based on an IP database but rather the # of attempts would be scoped by the IP address it was originating from. At some point you could completely lock out attempts from that IP. Sorry if that was unclear. This means that there in almost all cases the IP used by the bona fide customer would not be in locked out mode or in exponentially backing off mode yet. I understand relying on different IPs is not going to work 100% of the time, spoofing and NATs etc. are a (small) problem in this scheme. In such cases, the "locked out" message will be displayed and the bona fide user will get his email anyhow. (I guess if the attacker was just trying to be annoying to someone, he could hit the 'locked out' button over and over again, is that the point you are trying to make?) What I am saying is that I do not want the user to have to bother with resetting their password until the last moment. The fact that this is not a "bulletproof" solution is not an issue. Getting things down to much less likely is a win in this case because it means the customer's experience has been enhanced (or rather, has not been un-enhanced). "The sites that are going to get targeted are the ones that don't do lockout. The ones that do will be worthless, except to get your bots killed." I don't get the reasoning here. I want a system that both discourages getting specifically targetted like you are saying -- but also one that has a contingency plan if there is an attack. What we seem to be disagreeing about is the contents of that contingency plan? You want a simple one and I want one that will try to avoid the customer needing to even know there was a problem if possible.
- tptacek 18y ago
  "Reputation" is what the banks call this same solution, although it's just as silly there. My reasoning is, your solution is weak, and my solution isn't. Most user accounts are rarely or never used. IP based backoff is a speed bump for a coordinated attack against those accounts. Lockout completely stops it. And lockout is much easier to implement, which was my original point: people are wasting too much time thinking about this problem, and coming up with weird results.
  - timf 18y ago
    "IP based backoff is a speed bump" Exactly what I want from it. Speed bumps solve problems. Locking your car doors solves a problem. Neither guarantee anything but both have real effects which make people's lives better. That is, there can be another "N" here where the account gets shut down completely. If it ends up happening against one account from more than, say, 50 different IPs then shut it down and resort to inconveniencing the real user. Let's say 8 tries * 50 IPs, 400 is the new N where total cutoff happens. Too high? This makes it more likely that the bona fide customer won't be bothered by stupid script kiddies.
mseebach 18y ago
Make it reverse. Give known IP addresses a better reputation that unknown. Consider four zones: 1: the last three IP addresses the user has used; 2: any IP address the user has used more than 5 times; 3: any visit that has a valid "I've been logged in as user NN" cookie (given with expiry:never on every login); and 4: everything else. Lockouts are per zone. Chances are that your average automated attacker is always in zone 4, and that your legitimate user is always in zones 1-3, and that they'll never bother each other. You can then make a policy that's three tries and you're out for three hours, unless you verify your e-mail address. 24 tries a day should be low enough that dictionary attacks are infeasible.