GitHub users with weak passwords – you have been warned!
GitHub, one of the world’s biggest online repositories of software source code, is warning users to jolly well shape up when it comes to login security.
Of course, GitHub didn’t put it quite like that (it was a bit more polite to its customers), but we did.
GitHub was more diplomatic, saying:
This is a great opportunity for you to review your account, ensure that you have a strong password and enable two-factor authentication.
Concise, true and important.
After all, you can see why cybercrooks might want to take aim – even in a general, “let’s see whom we can hack today” attack – at a site like GitHub.
With millions of users and millions of software projects, small and large, free and proprietary, getting hold of other people’s GitHub logins gives cybercriminals the chance to take their attack straight to the source – literally and figuratively.
If you can compromise a software project before it even ships, by modifying its own source code repository, then you don’t need to waste time trying to find a vulnerability to exploit later on.
That’s exactly what happened to open source advertising server product OpenX earlier this year, with just a few characters of obfuscated, malicious PHP source code buried inside a JavaScript file buried inside a plugin that was part of the official software distribution.
So, what did GitHub do wrong?
Nothing, as far as we can tell – quite the opposite, in fact:
• Github offers two-factor authentication to improve login security.
→ By sending one-time passcodes to your mobile phone each time you login (or something similar using an app running on your mobile device), GitHub makes sure that a stolen or guessed password is not enough on its own for a crook to hijack your account.
• Github uses safe techniques to store its users’ passwords.
→ Github has followed all the advice, and more, in our recent article “Serious Security: How to store your users’ passwords.” We advised you to choose one of PBKDF2, bcrypt or scrypt as your password hashing mechanism; GitHub uses bcrypt. That means that passwords are never stored in plaintext; two users with the same password get a different hash; and brute force attacks are slowed down tremendously.
• GitHub uses rate limiting to take the edge off password guessing attacks.
→ If someone/something tries to login much more often than you might expect, you can wait longer and longer before responding to each login request.
According to GitHub, nearly 40,000 different computers have participated in this attack, presumably because the crooks involved have rented time on (or themselves own and operate) a large botnet.
A botnet is a loosely-coupled collection of co-opted computers infected with malware that regularly “calls home” to download instructions on what criminal act to commit next.
That can include keylogging for passwords, taking screenshots, stealing files, sending spam – or simply trying to login to GitHub with some supplied credentials, and reporting back if it worked.
With bcrypt slowing down each login attempt, and rate limiting making sure that no individual computer tries to log in too often, you might think that the crooks were wasting their time.
But a botnet of 40,000 devices nevertheless makes a realistic attack possible.
After all, if each computer tries to login just once every fifteen minutes, which would be a pretty feeble attack all on its own, the crooks can try 4,000,000 logins per day.
If they keep their heads down well enough to keep up this sort of work for a month, they get more than 100 million tries at GitHub users’ front doors.
And some of those front doors, we now know, are as good as open already.
GitHub isn’t saying explicitly, but it mentions that the crooks have been trying “passwords used on multiple sites.”
So it’s a good bet that the attackers are using data derived from Adobe’s recent megabreach.
Even though most of the passwords in the 150,000,000 records stolen from Adobe have not been worked out, millions of passwords have.
That’s thanks to users who chose unwisely, so that their passwords could be guessed straight from Adobe’s data. (One chap was even specific enough to write a password hint to say, “The password is password.”)
So please take GitHub’s advice, on GitHub and elsewhere: review your account, ensure that you have a strong password and enable two-factor authentication.
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/aBvyTtiy1z4/