The list of IPs from China (& Indonesia, etc) - that most are seeing on their page - making failed login attempts, looks like a botnet or automated bruteforce on the GitHub authentication service. Hit enough usernames with a dictionary attack and they'll get some accounts. I assume that GH are doing some basic rate-limiting or 'fail2ban' style blacklisting on these attempts.
As anyone who's put an EC2 up without securing it knows, an automated SSH attempt at 'root' will be made within a few hours of it coming online.
We wrote a script that hashed these passwords with the stored salt for each user and compared the result with the stored hashed value. Basically we brute forced everyone's accounts with the dictionary provided. Anyone who was found with an account that was in the dictionary was locked out with forced password change. We changed the password policy before doing this to increase complexity and block dictionary and the decrypted list words. We also force people to change their password every 28 days anyway and keep the last 7 hashed passwords and salts to verify that the user hasn't reused.
We store financial data so it's pretty hardcore auth requirements.
Seems more like its just background noise and they've just enabled reporting of it. I don't really see the problem everyone should have secure passwords anyway or two factor. If some random botnet can guess your password after < 50 guesses your doing something wrong.
If you need to store a personal access token in order to pull or push to your own repos, how is two-factor auth any better than a normal account with a secure (ie reasonably long, unique, randomly generated) password?
I use 2FA with GMail and the same question could be asked. The answer is that an application password does not have admin rights to the account. It can be revoked at any time. It traces the breach directly back to a particular application. They are not meant to be memorized but rather to be set and remembered in a particular application which means they can be extremely complex and are by default. I have to think that at least some of this is applicable to GitHub's 2FA.
Your points are good ones for something like GMail (where a single account allows access to many Google services and includes a potentially huge trove of other private data).
For github though, the the repos you have read (or commit if vandalism is the risk) access to are the data in question, so unless you use your github account for other things, I'm still not really seeing the benefit to the end user if you still have to store OAuth tokens everywhere you actually use git.
Can github issue OAuth tokens that are restricted to a specific repo? At least that would prevent a token leak exposing other repos that you had access to.
Very strange; I just checked my security history and see that there have been 5 unsuccessful login attempts from China/Venezuela to my account (last 14 hours).
Everything before that is pretty clean and without fake logins.
I too have the following, which cannot be attributed to me since I was asleep.
user.failed_login: Originated from 184.108.40.206 9 hours ago
user.failed_login: Originated from 220.127.116.11 11 hours ago
user.failed_login: Originated from 18.104.22.168 a day ago
user.failed_login: Originated from 22.214.171.124 a day ago
user.failed_login: Originated from 126.96.36.199 a day ago
user.failed_login: Originated from 188.8.131.52 9 hours ago
user.failed_login: Originated from 184.108.40.206 13 hours ago
user.failed_login: Originated from 220.127.116.11 17 hours ago
user.failed_login: Originated from 18.104.22.168 a day ago
user.failed_login: Originated from 22.214.171.124 2 days ago
user.failed_login: Originated from 126.96.36.199 9 hours ago
user.failed_login: Originated from 188.8.131.52 14 hours ago
user.failed_login: Originated from 184.108.40.206 19 hours ago
user.failed_login: Originated from 220.127.116.11 a day ago
user.failed_login: Originated from 18.104.22.168 2 days ago
9 hours ago user.failed_login: Originated from 22.214.171.124
15 hours ago user.failed_login: Originated from 126.96.36.199
2 days ago user.failed_login: Originated from 188.8.131.52
2 days ago user.failed_login: Originated from 184.108.40.206
Why does this page mean GitHub is experiencing security issues?
I didn't know this page existed. Its pretty handy, though I don't like how it shows failed logins. 6 attempts in the past 24 hours unnerves me. Probably trying my email and my use-all password from vBulletin or one of the numerous other sites which have been broken into.
It's showing a page of security history. That doesn't mean there is a problem with security.
It's just for the curious ones, or the paranoid ones, or those that surf around on suspicious networks or committed something last night and can't remember it at all.
6 hours ago user.failed_login: Originated from 220.127.116.11
12 hours ago user.failed_login: Originated from 18.104.22.168
16 hours ago user.failed_login: Originated from 22.214.171.124
a day ago user.failed_login: Originated from 126.96.36.199
a day ago user.failed_login: Originated from 188.8.131.52
2 days ago user.failed_login: Originated from 184.108.40.206
Strangely, I use a unique email for github, like I do with most sites that allow attaching "+comment" to the localpart of email addresses. Are attackers really this sophisticated, or where did they get the list?
Edit: Nevermind, I guess github allows authenticating with a username, in addition to the email.
That's only useful if they plan to use location algorithms like banks to detect possible fraud login's. For example banks do basic location tracking to detect fraud, if you mostly shop in New York in a specific area and they suddenly detect a purchase in Canada your bank should block it, I know my bank does and they'll call me within 20 minutes to confirm it was me (enough time for me to call them and authorize it or if I switch to another card, quick enough for me to tell them I'm in Canada for the week.)
That's a security risk in and of itself. Suppose someone has an account named 'bobs'. For whatever reason, they don't notice that they mistyped and put in 'bob' instead. They try a couple times with their correct password, and now the 'bob' user has in their logs someone else's valid password. Said user could then set up very minimal bits of automation to discover, and break in, to that account.
For one, because if someone does find a hole that gives them access to Github data, they'll have all password attempts, which would include typos of the real password. Which is a terrible, terrible thing to store in a hard drive (see Adobe)
For instance (just a quick idea): because if you make a mistake and enter your gmail password instead of your github password, now your gmail password is stored in clear text in their database, opening another can of worms etc.