9 ms·
How is this possible? I would expect repeated failed login attempts would force a timer making a brute force attack impossible? Or at least more difficult. Is t
by forrestthewoods 13y ago
How is this possible? I would expect repeated failed login attempts would force a timer making a brute force attack impossible? Or at least more difficult. Is that not the case or am I missing a key piece of info? (Serious question, not trying to troll or be smug.)
- ajtaylor 13y agoThe article did mention the use of 40k unique IP addresses, so I'm guessing their rate limiting is based on IP address and not the username or IP+username combination.
- X-Istence 13y agoWhy not both?
- fragsworth 13y agoMaybe they're doing this now that it's a real problem? At any rate, don't store really sensitive stuff on Github. It's a bad idea for many reasons, security flaws being one. In particular, keep in mind things like AWS server credentials which might go in your repository.
- rythie 13y agoDoing it by username means the real user can lose access to their account, whilst it is being attacked, even though they might have strong password.
- pavs 13y agoFrom the blog post: "While we aggressively rate-limit login attempts and passwords are stored properly, this incident has involved the use of nearly 40K unique IP addresses. These addresses were used to slowly brute force weak passwords or passwords used on multiple sites. We are working on additional rate-limiting measures to address this. "
- Pxtl 13y agoI've seen this mentioned before - using a tremendous number of IP addresses across a tremendous number of sites and over a massive length of time to perform a very low-grade incessant brute-force attack. It means that any weak password anywhere is always vulnerable because everybody is always under low-grade brute force attack.
- ChuckMcM 13y agoThis is one of the more insidious scraping techniques. At Blekko if we see the same exact same query coming in from a bunch of different addresses, differing only by which page of the results they want we temporarily ban the entire lot of them. I'm sure a similar situation would work here, especially with a decent geoip database. If you get 3 - 5 failed attempts on an account separated by more than a few miles (and not along an interstate :-)) you can probably assume someone is using a botnet to try to break in.
- recuter 13y agoHow does IPV6 affect things?
- gnur 13y agoIt is probable that a single machine gets a /64 ipv6 range, but the first 64 bits are consistent. When ipv6 gets more common it will probably be more acceptable to block an entire /64 if you suspect a brute force attack.
- dredmorbius 13y agoAs with IPv4, DoS attacks which tend to be clustered from specific locations (I've seen them originating from multiple hosts within a hosting center's range, or from a particularly poorly managed ISP's allocation), using broader allocations (CIDR blocks and ASNs) to identify responsible networks can be useful. The challenge in general is translating from IP addresses to the administrative block responsible (there are IP reverse lookups which do this, in some cases the zonefiles are downloadable allowing lookups at local network speeds), and in translating the information to some sort of policy (few network management devices offer AS blocking rules, though CIDR is pretty much native).
- beering 13y agoYou may not be trying to troll, but either you didn't bother reading the article or they added details since you read it (doesn't seem likely). They answer this near the end of the not-very-long article.
- forrestthewoods 13y agoHrm, so they do! I swear I read the article a second time and even re-skimmed looking for that detail before making my post. My brain really, really wanted to not read that next to last paragraph. Stupid brain.
- deleted 13y ago[deleted]
- jcampbell1 13y agoThe attack was done using 40,000 IP addresses. You can only force a timer per IP address.
- muglug 13y agoYou can also force a timer on a per-account basis - e.g. twenty failed logins for one account from five different IP addresses -> set a timer on those IP addresses and a timer on that account. It's not simple, but it would help mitigate a mass-brute-force effort.
- schrodinger 13y agoBut then it's trivial to lock someone out of their account by trying to login as them a bunch of times. That's why they'd key it based on ip and username, not ip alone.
- rurounijones 13y agoRate-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).
- shill 13y agoI have a single failed login from an IP address in Brazil 16 hours ago. And another single failed attempt from an address in Thailand three days ago. No suspicious activity had been logged before that. The attacker probably tried a password like 'github' on the first pass and 'password' on the second pass.
- stokedmartin 13y agoOne could attempt to log in from multiple IPs over a long span of time, let's say weeks. This scenario is difficult to trace using timers. Alternatively, sending email alerts on each failed log in attempt may not very optimal and generate a lot of false positives - person A (not an intruder) randomly tries logging in by impersonating multiple github users. IMO something similar to SSH security policies like allowing logging in from a set of IPs and/or without password i.e. using public key, may be a good idea.
- scovetta 13y agoWhat if the attackers were brute-forcing the username given a common password? Instead of: foobarjones:123456 foobarjones:passwd foobarjones:test Do: foobarjones:123456 drsmith:123456 ilikeorangejuice:123456 ... (some time later) foobarjones:passwd drsmith:passwd ...