Github hit by massive password guessing attack

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: 

via nakedsecurity