See "Part VII" of this SO answer from Jeff Atwood describing mitigation techniques for "distributed brute force attacks"

http://stackoverflow.com/questions/549/the-definitive-guide-...

TL;DR - compute the average number of system-wide failed password attempts, and if it's over the norm, impose small delay on all users (except those that login via a persistent login cookie).

Actually, this answer isn't by Jeff Atwood. See http://meta.stackoverflow.com/questions/95172/old-problemati...

Ah - my mistake. Thank you for clarifying.

Note that this can be very tricky. You don't want to keep connections open or waiting.

Very useful, thanks!

Rate limiting is not the only thing they could have done. They could also notify users of failed attempts and ask them to confirm it was their attempt (once they were logged in of course) - the offending IPs could then be blacklisted.

Of course, this works only if the number of attacks is small enough.

I think the point is that with so many source IPs, blacklisting techniques are pointless, and given the duration of the attack, timeouts are useless too. What is better is a IP whitelist coupled with a notification if a certain number of logins fail from IPs outside of that whitelist, regardless of the time inbetween. Users with strong passwords could disable this notification but it makes others aware that they are under this attack (possibly).

An even more secure approach is what Linode does. If you log in from a non-whitelisted IP, they require you to whitelist the IP via an emailed link, then you can login.

But that's overkill and the first one is a lot better for casual websites. You store the user's last login IP and you wait for maybe 1024 failed attempts not from that IP, which ought to be enough to suggest a bruteforce attack. You're protecting "bluedog4", not "password" or "1234" which are going to get cracked anyway.

Couldn't the server check for a "trusted IP(s)"?

Two-Factor Authentication is great but even without, it would seem that they could more aggressively lock out any new IP address which is failing password retries several times. (but continue allowing log-in from trusted IP's.)

IPs aren't stable. For instance, the legacy SSID broadcast all across my university assigns you a new (usually different) fully routable public IP every time you authenticate through the captive portal. Some random person enjoys the "trustedness" of your IP at the time of login; you never see it again.

There is a new SSID with WPA2-EAP replacing the captive portal and the usual DHCP/NAT business replacing our massive waste of IPv4 space, but that was implemented last year. This introduces the opposite problem: one person out of thousands can't remember their GitHub password so GitHub mysteriously drops all traffic from everyone on campus.

IP addresses don't identify people, computers, or usefully discrete units of any kind.

While that seems like a logical solution arrived at through a pragmatic approach, it's toeing the line of a really bad practice. IP addresses are not, and should not be, identifiers like this, especially when you're talking about a whitelist. What happens if the ip address changes (happens all the time for the majority of US internet users who have dynamic IP's)? What about if they want to work at a coffee shop?

While it might be possible to do all this correctly, it's just so easy to do wrong that it's hardly worth it. Given that there are existing better ways to do it, it's the kind of thing you probably don't even want to mess with.

I suppose if you see repeated failures across a range of IP addresses you could temporarily block the entire account and send a reactivation email to the registered email address.

That would prevent a practical joker at work from locking you out unless he went to a lot of extra trouble.

At some point I'm starting to see the appeal of completely abandoning passwords in favour of email or SMS-based token creation.

You attempt a login, they send an out-of-band request for confirmation. You do the confirm, and they let you in. Like a superfast streamlined version of the "reset password" email.

The existing 2 factor auth basically does this, without the requirement of SMS, internet, or any connectivity really in general. The OTP tokens are based on time or a counter, and a secret key.

Considering Github is frequently the target of DDoS attacks, I would assume there are people willing to go to a fair bit of trouble to lock you out of your account.