5 ms·
Rate-limiting based purely on username/password is a great way for me to lock other people out of their accounts (Or force them to do a password reset, or wait
by rurounijones 13y ago
Rate-limiting based purely on username/password is a great way for me to lock other people out of their accounts (Or force them to do a password reset, or wait for a timeout) by just failing to login to theirs a few times.
The way around this problem is to add source IP into the rate-limiting algorithm so that I cannot mess someone else up.
Unfortunately that can be worked-around somewhat by using 40k different source IP addresses.
No perfect answer. Personally I think GH did ok here.
- ams6110 13y agoI 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.
- eli 13y agoConsidering 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.
- Pxtl 13y agoAt 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.
- oomkiller 13y agoThe 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.
- evanspa 13y agoSee "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-to-form-based-website-authentication 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).
- rurounijones 13y agoVery useful, thanks!
- jakobe 13y agoActually, this answer isn't by Jeff Atwood. See http://meta.stackoverflow.com/questions/95172/old-problematic-question-edit-or-delete http://meta.stackoverflow.com/questions/95172/old-problemati...
- evanspa 13y agoAh - my mistake. Thank you for clarifying.
- ohwp 13y agoNote that this can be very tricky. You don't want to keep connections open or waiting.
- ajcarpy2005 13y agoCouldn'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.)
- superuser2 13y agoIPs 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.
- lelandbatey 13y agoWhile 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.
- annnnd 13y agoRate 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.
- tmallen 13y agoI 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.