Skip to content
Naked Security Naked Security

Github hit by massive password guessing attack

Crooks have been guessing away at passwords on popular source code storage site Github...but you don't re-use passwords, do you?

Github is a well-known on-line repository for software source code.

It’s free for open source projects (personal and business users have to pay), and the site is said to have 14,000,000 users who collectively maintain 35,000,000 repositories.

The idea of a software repository is that it isn’t just a place to store your source code, but also to keep control of it.

You can monitor who changed what, and when, and approve or reject the code modifications; you can make sure your documentation keeps up with your software’s features; you can look after multiple versions of your product at the same time; you can keep track of bugs and bug fixes; and much more.

Generally speaking, in any well-curated software project, a source code repository is a critical part of building and updating the product.

Once you’re ready to commit to a new version, you download the latest-and-greatest official source code, often as part of some kind of automated production process; build it into a package containing your updated application; perform a set of acceptance tests; and then you’re ready to go live.

In other words, if someone outside your product development team were to get hold of your Github password, they could wreak havoc.

Because of the version control system that lets you undo unwanted changes, you’d probably be able to get back to where you were, but it might take a lot of time and effort to make sure you reversed out all the unauthorised alterations.

Beware sneaky changes

Worse, however, an attacker with your password could make small and subtle changes, burying them deep in your code, perhaps sneakily “authorising” their unlawful alterations along the way so that they would pass muster, and even modifying any associated tests to keep you unaware of the tweaks.

If that were to happen, trust in your project would be seriously harmed: the interlopers could install a backdoor, or even simply claim to have installed a backdoor, and you’d be faced with going through everything with a fine-toothed comb to make your code trustworthy again.

So it’s worrying to read, on Github’s blog, that the company has detected a large-scale attack involving a huge number of unauthorised login attempts.

There’s no suggestion that Github was breached.

But this does look as though crooks with a large list of passwords from some other source, such as an earlier breach against a completely different company, have decided to see just how far those already-known passwords will get them.

Something similar happened to Twitter recently: 33,000,000 Twitter “logins” were put up for sale, and at least some of them turned out to be correct.

(The fact that not all the Twitter “logins” worked suggests either that the data was very old, or that those users who had picked a different password for every account were safe.)

Github is in the process of doing password resets “on all affected accounts,” and notifying those users whose accounts were involved:

In order to protect your data we’ve reset passwords on all affected accounts. We are in the process of sending individual notifications to affected users.


If your account was impacted, we are in the process of contacting you directly with information about how to reset your password and restore access to your account.

The company hasn’t said whether it’s resetting passwords on every account that was tried by the crooks, or only on those where unauthorised login attempts seem to have succeeded.

What to do?

Github supports two-factor authentication (2FA), using a variety of methods including setting up a mobile-phone based authenticator app to generate one-time login codes, or via SMS text messages that deliver a single-use code to your phone every time you log in.

Two-factor authentication doesn’t prevent crooks from taking over your account, but it makes things much more difficult for them.

In particular, because there’s what you might call a “secondary password” that changes every time you login, crooks who acquire your account credentials from an earlier breach can’t simply login whenever they want, because they can’t predict the one-time codes that they’ll need in the future.

Better yet, if you are using SMS-based authentication, you’ll get a login notification message (one you weren’t expecting, to serve as a warning) every time someone else tries out your regular password.

Three quick tips:

  • Don’t re-use passwords. Never! Crooks will try a stolen password from one account against all your others, so don’t make things easy for them.
  • Turn on 2FA. It makes yesterday’s password breaches much less useful to today’s crooks, because of the every-changing login codes.
  • Watch our How to Pick a Proper Password video. It’s easier than you might think to come up with passwords that crooks are unlikely to be able to guess:

(No video? Watch on YouTube. No audio? Click on the [CC] icon for subtitles.)

Learn more about 2FA

(Audio player above not working? Download the MP3, or listen on Soundcloud.)


Can always check the commits for ones not made by you.

The mess caused by an upstream rebase is going to be obvious.

It is common for email addresses to be public on github. I wonder if they are hoping that passwords have been reused for email accounts.


If the hacker successfully guesses your password, then their commits will appear to be made by you. They might also have done a git rebase to meld their bad commits with your good ones, so that it is not obvious that the commits in github are different from the code you uploaded.

If you have a local copy of your git repository that you took before this hacking attack, the correct way to detect changes would be to do a fresh checkout of the suspect repository (from github), and the compare it to your know good (old local) repository.


If your nemesis *is logging in as you*, then you (or your chums who share QA duties) are going to have to figure out which of the changes really were yours, and which ones were done by the fake you :-)


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!