4 ms·
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
by 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.