Would it work to do that by IP, and allow only X different IPs for an account to try to login on a single day? e.g. if you've tried to login with 10 different IPs on that day, you will no longer be able to login that day. (Of course this would mean saving some extra data.) The biggest problem I see is that this means people can lock you out of your account, which is probably unacceptable.
What my bank does (and PayPal too if I remember correctly) is keep track of my IP, and if it changes then it forces me to enter additional data about my account before letting me continue. (This assumes I got the password correct.) I think one or both also may use some cookie(s) to mitigate changing IPs. They may also make use of leaky browser data (like user agent strings etc.) to help identify me; they have the potential to see a lot since I'm not trying to hide from them.
I don't see anything wrong in principle with "account lock out" provided that it doesn't affect existing sessions and provided that you can just ask the site to send an email with a token to reset your password. Spammers can lock a user out, so what. Minor inconvenience. If it's happening a lot to the same user and it's also affecting the user negatively, something extra could be done to minimize lockouts for the actual user (who should be easy to detect by the server through logs and a premise the user isn't trying to hide).
Spammers are able to flood you with "forgot your password?" emails, too. I don't know how often they do it. I had my first wave in after 7 years of the same email just a few months ago mostly from old sites I forgot I even had accounts on.
I'm not really a fan of the exponential backoff idea proposed earlier above, I'd sooner go with the "X tries, then wait" approach. The lockout time should not be more than 24 hours, ideally less. Though one could also set the lockout period to expire when the user's session automatically expires, if there's a current one, but that may be too clever.
I feel that there are really two pieces of advice to give on dealing with spammers for the general case... Advice for low-traffic sites and advice for high-traffic sites. I don't have any advice with high-traffic sites since I have no experience with spam at that level (and by high-traffic I mean thousands to millions of uniques per hour), though I don't think the status quo is good enough. With low-traffic sites spam behavior is easy to detect and create a custom solution against. Custom solutions are often better than the popular stuff just by virtue of not having anyone targeting them specifically, and even if that's the case it's still easier to cat-and-mouse if the main options against spam aren't acceptable. Something as dead-simple as loading your form with javascript (or dynamically changing the URL endpoint when the submit button is clicked to something different than what's reported by the form's html attribute...) stops a lot of bots regardless of a captcha, even though you sacrifice the Lynx users. And in my own anecdotal experience I've had more success (less spam bots getting through and leaving a message) with a captcha like "Please join these two "words" together (without spaces): taeiswovd and brhpugqc" than with ReCaptcha even though it'd take less than a minute to add a parser for mine in a bot program. I used to use an arithmetic question but even the dumb bots are on to that one these days--at least the ones after my comment boxes. (I don't even think they added, they just tried numbers 0-99 and sometimes got lucky.)
PayPal doesn't ask you for some extra data. It blocks ("limits") your account so you can't actually use it until you provide them with a copy of your utility bill or something. Terrific when you're on vacation and need to make a PayPal payment. That had me so pissed of that I closed my account (which isn't possible whilst it's "limited" unless you manage to get them on the phone -- good luck with that. -- at least you can then tell the person on the phone that you think they're full of )
>at least you can then tell the person on the phone that you think they're full of
Why? The poor soul answering support calls likely didn't make this policy and cannot do anything to change it. I guess if you like just unloading anger at some unempowered person who has the responsibility of taking a bunch of crap without reacting in turn then this is a good idea. Otherwise it is more useful to take your business elsewhere, and if you must try finding someone to complain towards that might actually be able to encourage change.
Yeah, PayPal does a lot of crap... But I was buying some stuff on a different-than-usual computer and place just a few weeks ago, and it made me provide my bank account number as verification before it would let me send the payment. (Had to sign into my bank account to find a scan of an old check to read it off of..) In a similar vein, Amazon requires reentering your credit card every time you send to a new shipping address.
Why do you call that crap? A normal bank would do something similar. Try traveling to another country and using your ATM card, it likely won't work unless you call your bank ahead of time and tell them of your travel plans.
That prevents brute force attacks against one specific account, but not against an attack against all users of a site. If you have the capability to make, say, 10k login attempts per second (no idea if that's realistic), you don't slow down to 1 attempt/second, you just attack 10k different accounts once every second.
IP blocks can be countered in other ways (botnets, tor, etc).
I'm not saying it's a bad idea though, there doesn't seem to be any downside apart from the book-keeping required. You could probably start with a higher delay (5 to 10 seconds seems very reasonable) and increase it to several minutes. But please don't make it 24 hours after 3 failed attempts, which happened to me when I tried to order train tickets online and forced me to make a trip to a physical ticket vending machine.
The site should have the capability to detect login attempt for multiple attempts - Show captcha
Same account login attempt from multiple IPs - show captcha
With the above: a simple time wait for next attempt could solve the issue for most legit attempts right?
I believe a cookie is a datum given by the server to the client so that the client may present it to the server when making requests later. This is entirely voluntary on the part of the client; the client is free to pretend it has never received any cookies, or to present a made-up cookie (though the server would likely recognize that as suspicious). Browsers are likely to mindlessly accept cookies from servers and to obey servers' instructions as to when to present the cookies back to the server; but obviously a bot is likely to be more sophisticated, and to not present any cookies other than ones that say "You have successfully authenticated yourself as user xxx".
