GitHub resets user passwords following rash of account hijack attacks

As many as 40,000 unique addresses flood site with fraudulent login attempts.

GitHub is experiencing an increase in user account hijackings that's being fueled by a rash of automated login attempts from as many as 40,000 unique Internet addresses.

The site for software development projects has already reset passwords for compromised accounts and banned frequently used weak passcodes, officials said in an advisory published Tuesday night. Out of an abundance of caution, site officials have also reset some accounts that were protected with stronger passwords. Accounts that were reset despite having stronger passwords showed login attempts from the same IP addresses involved in successful breaches of other GitHub accounts.

"While we aggressively rate-limit login attempts and passwords are stored properly, this incident has involved the use of nearly 40K unique IP addresses," Tuesday night's advisory stated. "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. In addition, you will no longer be able to login to GitHub.com with commonly used weak passwords."

The attack comes a few weeks after recent high-profile hacks on Adobe, MacRumors, and vBulletin have exposed huge numbers of account credentials. It's possible the infusion of so many newly compromised records is at least in part what's fueling the attack on GitHub, although the advisory made no reference to them.

To the strong credit of GitHub, the site said it uses the bcrypt algorithm to cryptographically hash passwords. Use of bcrypt and other slow hashes dramatically increases the time and resources required to crack passwords in the event they are ever obtained by hackers. Such "offline" cracks differ from the online attacks described in the advisory, however.

Promoted Comments

From what I've heard it sounds like the attack is quite broadly targeted. I've confirmed that my account (not a high-profile account) has had numerous failed login attempts all on the same day. Other developers at my company have reported similar findings and I've heard many similar stories from other developers I know. Whoever is doing this isn't exactly being subtle about it.

Are these attacks targetting high-profile users? It seems to me that most accounts on github would not be very valuable to hijack - unless perhaps they want to use the hijacked accounts to commit some subtly malicious code, or something like that.

Adding a back door or other vulnerability to a popular project, committed by the project owner? That's a potential gold mine.

To the strong credit of GitHub, the site said it uses the bcrypt algorithm to cryptographically hash passwords. Use of bcrypt and other slow hashes dramatically increases the time and resources required to crack passwords in the event they are ever obtained by hackers. Such "offline" cracks differ from the online attacks described in the advisory, however.

As has been pointed out many times before by the likes of Ars, it really doesn't matter how good GitHub are, if an attacker has managed to get a few passwords associated with your email address from previous hacks of other sites, then they have a few really good guesses of your GitHub password.

We either need all sites to be using something like bcrypt, or we need to use different passwords for all sites.

42 Reader Comments

Are these attacks targetting high-profile users? It seems to me that most accounts on github would not be very valuable to hijack - unless perhaps they want to use the hijacked accounts to commit some subtly malicious code, or something like that.

From what I've heard it sounds like the attack is quite broadly targeted. I've confirmed that my account (not a high-profile account) has had numerous failed login attempts all on the same day. Other developers at my company have reported similar findings and I've heard many similar stories from other developers I know. Whoever is doing this isn't exactly being subtle about it.

Are these attacks targetting high-profile users? It seems to me that most accounts on github would not be very valuable to hijack - unless perhaps they want to use the hijacked accounts to commit some subtly malicious code, or something like that.

Adding a back door or other vulnerability to a popular project, committed by the project owner? That's a potential gold mine.

Are these attacks targetting high-profile users? It seems to me that most accounts on github would not be very valuable to hijack - unless perhaps they want to use the hijacked accounts to commit some subtly malicious code, or something like that.

Are the ultimate goals of the attacks known?

What other sites would a typical Github user also be a member of? Maybe they reuse the same password for the company's internal network.

If it's in any way tied to the previous breaches of Vbulletin etc. it might just be an attempt to make the most of those leaked passwords.

To the strong credit of GitHub, the site said it uses the bcrypt algorithm to cryptographically hash passwords. Use of bcrypt and other slow hashes dramatically increases the time and resources required to crack passwords in the event they are ever obtained by hackers. Such "offline" cracks differ from the online attacks described in the advisory, however.

As has been pointed out many times before by the likes of Ars, it really doesn't matter how good GitHub are, if an attacker has managed to get a few passwords associated with your email address from previous hacks of other sites, then they have a few really good guesses of your GitHub password.

We either need all sites to be using something like bcrypt, or we need to use different passwords for all sites.

On a related note, this is one of the reasons you should use a password manager such as LastPass and others. I use LassPass but many other works great as well. You can also use it to store secure notes such as GitHub's recovery codes for 2FA.

Reading this story after reading about the plaintext password dump that happened on the Cupid Media site results in some provocative speculation concerning the relation of hook-up sites to code repositories.

I wish more sites would be proactive and find these lists of passwords and just disallow them. It is sad that you can easily find password lists that have come from real password hacks yet they still work on 90% of the internet.

We need to stop allowing shitty passwords. Kinda makes me wish that a random password generator was built into chrome/firefox/ie. It won't solve every problem but if it was 1 click to get a random password that is then saved in your browser for you I think more people would use that. You then have to deal with the browsers auto-backing up passwords to the clouds but that is a smaller issue.

I checked my account history - there were 5 random login attempts to my account, spanning from 3 days ago to 2 days ago. The weird thing is that I used a different email for my github account, the email is not compromised (according to google), and I've never made any commits or anything with my account. The first two IP addresses (3 days ago) traced to Russia and Venezuela; The other three (2 days ago) came up on proxy lists when I googled them.

I wish more sites would be proactive and find these lists of passwords and just disallow them. It is sad that you can easily find password lists that have come from real password hacks yet they still work on 90% of the internet.

We need to stop allowing shitty passwords. Kinda makes me wish that a random password generator was built into chrome/firefox/ie. It won't solve every problem but if it was 1 click to get a random password that is then saved in your browser for you I think more people would use that. You then have to deal with the browsers auto-backing up passwords to the clouds but that is a smaller issue.

Are these attacks targetting high-profile users? It seems to me that most accounts on github would not be very valuable to hijack - unless perhaps they want to use the hijacked accounts to commit some subtly malicious code, or something like that.

Are the ultimate goals of the attacks known?

There is a few things I'd be very worried about:

- Injecting vulnerabilities into the sourcecode - Scraping config files for production log in details (FTP or MYSQL), some don't ignore these for commits - Whitebox penetration testing, it's a lot easier to hack into an application if you can see the source code

Hmm...6 failed login attempts in the past 3 days, all from different IPs, none of them me, and I am the only successful one. I suppose it couldn't hurt to change my password anyways though. Good to see one of these sites being targeted using a proper password hash though, I received an email from a site last week that got their passwords stolen and they use MD5 *facepalm*

Are these attacks targetting high-profile users? It seems to me that most accounts on github would not be very valuable to hijack - unless perhaps they want to use the hijacked accounts to commit some subtly malicious code, or something like that.

Are the ultimate goals of the attacks known?

Don't know the ultimate goals but they were attacking my account because my primary email on GitHub is the same as the email that was in the adobe leak. Thankfully the passwords were different but still this whole situation sucks.

I too have had many failed attempts in the past few days. I'm a total nobody (I'm a grad student with only a couple random small repos and no association with any company). Seems like they're doing entirely random attacks.

My password actually wasn't very good so I did end up reseting it...I guess I should probably use a password wallet for that site too...

edit: I guess my email address and password could be in the adobe hack. That's unfortunate since I probably used a lazy throwaway password for that...I guess I may have to entirely stop using throwaway passwords under all circumstances...eventually I'll slip up and have something important behind a weak password.

Hmm...6 failed login attempts in the past 3 days, all from different IPs, none of them me, and I am the only successful one. I suppose it couldn't hurt to change my password anyways though. Good to see one of these sites being targeted using a proper password hash though, I received an email from a site last week that got their passwords stolen and they use MD5 *facepalm*

Yeah, I've had 5 failed attempts in the past 3 days. It's funny to me that so many sites out there use those old hash algorithms. The funniest thing about it is BCrypt and its ilk is not hard to use. I mean, I could understand if you had to learn advanced cryptography to take advantage of the tool, but you don't. BCrypt is a black box API that's got 4 pregnantly named functions (GenerateSalt,HashPassword,HashString,Verify).

This does sound like someone got a list of usernames and is just trying really obvious things (like password and the user's username) in the hopes of finding at least a few accounts.

Nobody has noticed any successful logins from IPs you don't recognize right? If whomever is doing this has people's passwords, he sure isn't have much luck with them.

It seems doomed to fail unless they have a password/username/email cross reference. I'm not sure what anyone could hope to achieve brute forcing accounts with 5 attempts spread over days. Even if I choose a single digit number, it would take a week at their rate. I know people choose weak passwords, but this...

Make a database table with hashes public. If you can't stop people from cracking the hash, then it's not secure. Don't rely on obscurity of the table. Change what you are storing in the table to prepare as if it will be compromised. Try something like variable-length hashes, or even multiple hashing algorithms to choose from using a time-stamp that is itself encrypted.

- Log into GitHub and go to https://github.com/settings/security- Scan for "user.failed_login"- Grab the IP address (you can click the entry for an easier copy/paste pane)- Find an IP address mapper (I googled quick and found http://www.infosniper.net/ – if anyone knows better, lemme know) and enter it- Get completely spooked that your account has failed login attempts from Seattle, Slovenia and Sao Paulo- Read up quick on the Ars password manager article here - http://arstechnica.com/information-tech ... d-manager/- Decide to dramatically accelerate the transition you were slowly making to living in 1Password (~$70 for a Mac app and a PC app, synced with DropBox = actually convenient!)

To the strong credit of GitHub, the site said it uses the bcrypt algorithm to cryptographically hash passwords. Use of bcrypt and other slow hashes dramatically increases the time and resources required to crack passwords in the event they are ever obtained by hackers.

In the case of this attack, the use of bcrypt is using up Githubs resources and not the attackers, which is a bit ironic

Out of an abundance of caution, site officials have also reset some accounts that were protected with stronger passwords. Accounts that were reset despite having stronger passwords showed login attempts from the same IP addresses involved in successful breaches of other GitHub accounts.

If the passwords were hashed with BCrypt, how did GitHub know which passwords were "weak".

Either way, I started using KeePass a bit more than a year ago. I prefer it too these online password managers because it is local only (unless you sync your file with Dropbox or something) and open source (I'm pretty paranoid). I think I have changed my passwords on every important service to at least a couple dozen random characters (except when the service limits me...), but you still might be able to break into, say, my old GameFAQs account.

If the passwords were hashed with BCrypt, how did GitHub know which passwords were "weak".

you feed a list of weak passwrods through their own code and compare weak hashes to the user hashes..

Makes sense, I suppose. But tell me this: If you're correct, how does GitHub handle salts (assuming they do salting)? Salts would require engineers to check the hash of each user. If they're using bcrypt, that's going to be a big undertaking, no?

Seems great that GitHub, Facebook and other companies are going through the trouble to make sure users don't choose weak passwords. But does this mean they're not salting? Anyone know?

1Password does something similar where it saves the strength next to the password. Probably saves a lot of processing power not having to re-calculate all the time.

I was thinking they might do that too. But it occurs to me that this is actually a bad idea, because if someone then got their hands on the hashes, the strength value would tell them which passwords they could easily break. It might not make a big difference, but it would be addition information that could be used to break the passwords; and there are very few benefits to storing that strength value anyway.

1Password is a bit different, because it stores the actual unhashed password.

Are these attacks targetting high-profile users? It seems to me that most accounts on github would not be very valuable to hijack - unless perhaps they want to use the hijacked accounts to commit some subtly malicious code, or something like that.

Adding a back door or other vulnerability to a popular project, committed by the project owner? That's a potential gold mine.

Some companies store code but it is not disclosed on their public site.

If the passwords were hashed with BCrypt, how did GitHub know which passwords were "weak".

you feed a list of weak passwrods through their own code and compare weak hashes to the user hashes..

Makes sense, I suppose. But tell me this: If you're correct, how does GitHub handle salts (assuming they do salting)? Salts would require engineers to check the hash of each user. If they're using bcrypt, that's going to be a big undertaking, no?

Seems great that GitHub, Facebook and other companies are going through the trouble to make sure users don't choose weak passwords. But does this mean they're not salting? Anyone know?

It sounds like they might not really know if the password is "strong", just that an IP address that broke into one account tried to do the same to another account and failed.

If the passwords were hashed with BCrypt, how did GitHub know which passwords were "weak".

you feed a list of weak passwrods through their own code and compare weak hashes to the user hashes..

Makes sense, I suppose. But tell me this: If you're correct, how does GitHub handle salts (assuming they do salting)? Salts would require engineers to check the hash of each user. If they're using bcrypt, that's going to be a big undertaking, no?

Seems great that GitHub, Facebook and other companies are going through the trouble to make sure users don't choose weak passwords. But does this mean they're not salting? Anyone know?

As the password arrives as GitHub's back end un-hashed, it would make sense to do any checks then, at log-in.

I have been considering an internet start-up idea for a while now, but have never got round to doing anything about it: Maintain a list of all the known-bad passwords you can (i.e., the ones the bad guys have found from hacks) and stick them in a web-service-exposed DB. Sell this service to websites like GitHub, and also smaller sites that can't afford the effort of doing it themselves.

When someone logs into your clients site, the client pings your server with the password. The client site acts appropriately (either just tells the user their password is known-bad, or additionally makes them change it).

Do the same with known compromised email addresses (maybe).

You can send a bcrypt version of the password instead of plain text so you don't have to trust the service (or the NSA/GCHQ/FSB), obviously you then have to hash your whole bad-password DB.

Make a rate-limted browser version available for free, charge for an unlimited web service.

You have to think carefully about security, and make sure no one spoofs your site and starts harvesting passwords, so maybe you really DON'T want to accept queries in any un-hashed form.

The reason I haven't done this myself is I expect - like the RFID cat flat idea I had - someone else must already be doing it? Also, I don't want to maintain a list of known-bad passwords.