[hobin]

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.

[Jach]

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.)

[shdon]

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 )