Ok, so the breach was via an employee's Github account that wasn't secured with 2FA. I understand that would have given them access to the source code for 8tracks, but HOW did they get access to database credentials?? I would have assumed best practice would dictate that database server IP addresses and access credentials would have been in a configuration file that is NOT checked into version control??

Most companies go to great lengths to extract credentials, keys and other sensitive information into some sort of environment file, don't they?

Unless they had a copy of their database in text/JSON/XML format uploaded to version control as well??

> However, it did allow access to a system containing a backup of database tables, including this user data.

Sounds like they store backups with git and push them to GitHub (presumably Git LFS). Someone should tell them that Git is not a backup solution. It's also possible they were using some backup service that uses GitHub SSO (not sure if that's better or worse).

It's good to see they finally took advantage of GitHub's feature that restricts user access to an organisation if they don't have 2FA. Every organisation should enforce that.

The backups could have been stored in a system protected by github SSO perhaps.

Ah, I hadn't thought of that. Makes sense that this could have been the case.

8tracks could have a backup system that uses Github as the identity provider, the backup data wouldn't have to reside in a repo on Github. As a PSA to others using Github organizations and allowing login via Github, there is a setting you can turn on to require MFA for all the members of the org.

https://help.github.com/articles/requiring-two-factor-authen...

They don't explain exactly how, but yes the attacker did find a database backup. Apparently the production systems were not accessed.

FYI, you can limit access to repos to accounts that have 2FA enabled. I'm encouraging clients to enable that option. Users can't accept an invite to the repo until they turn on 2FA.

It's really never reasonable. Even if your VCS is already secure, inserting credentials means bringing it up to spec with actual credential storage policy, even if that means inconvenience to the developers - and if it's not inconvenient, your policy is probably too lax in the first place. There should be a total separation of concern between your code and user credentials.

Ansible vault, separate repository to the code and you're fine. You're up shit creek if you lose your code too unless you're 100% perfect so there is no distinction in policy.

Hell if you're using vault you might as well chuck the config in with the code. The vault key distribution is what needs to be controlled.

There is a real difference in company impact between leaking your code and your credentials. If your code and credential policies are the same, your company has a serious problem of priorities, since it's either not protecting credentials enough, or it's slowing down developers too much.

The trick is to make sure that if the credentials do leak they are useless.

I have never seen a company that didn't store some credentials in their VCS.

To the point where you see weekly TIFU /r/cscareerquestions post on a junior using training material and then accidentally trashing the production db.

That doesn't happen because you don't let them have the credential vault keys. In fact no humans get them; just the build and deployment pipeline.

> If you signed up via Google or Facebook authentication, then your password is not affected by this leak

This is why it drives me crazy when I click "login using google" and then it immediately prompts me to create an account with only my email filled in.

Thanks for letting us have access to all your personal data!

This is not how "login with google" works. Instead it's using Google/Facebook/whatever as a trusted third party to authenticate you.

But Google/Facebook/whatever can trivially link all of your accounts through the SSO (and when you access your accounts). Of course, Google can get some of that information from GMail and both can get it from tracking (and GP was talking about the other way around), but it is something to consider.

What I'd like to know and is lacking from this disclosure is what data they stored and was leaked from users, and the hash algorithm they used.

Motherboard[0] talks about 18 million accounts compromised, stolen data includes usernames, emails and SHA-1 hashed passwords.

[0]: https://motherboard.vice.com/en_us/article/mbjm83/hacker-ste...

> Although the decryption of one particular user’s password through brute-force techniques is unlikely,

This doesn't seem true to me given that many people use weak passwords (even when they think they don't).

Here we go again. We see these happening to often.

That the Github account did not use 2FA does not explain the breach. How did the attacker get the password?

At least the passwords were hashed. I wonder what hash they used though. I'm tempted to bet good money it's going to be an inadequate one like SHA1 or a completely broken one like MD5.

When the purpose of hashing is protection of passwords, MD5, SHA1, SHA256, etc. are all effectively equally broken. MD5 vs. SHA1 makes no real difference here.

You can usually tell a company's security posture when they say "all passwords were hashed and salted" without listing the hashing algorithm. If they're using an algorithm actually suited for password hashing, like bcrypt, they'll usually state the name of the algorithm.

To be honest I know that MD5 vs SHA1 or SHA512 is irrelevant in terms of password hashing, but personally seeing SHA512 would make me laugh a little less than MD5. Both are inadequate for this particular use-case, but at least seeing the modern hash would mean they tried to do the right thing.

SHA-1 and MD5 are susceptible to collisions, not pre-image attacks, so replacing either with SHA-256 wouldn't really impact this scenario. The real question is whether they used iterated hashing (and to what degree), peppering, a keyed hash, or something else that would slow down a dictionary attack.

I don't think OP suggested otherwise?

While "inadequate" and "completely broken" are totally valid qualifiers for those hashing algorithms, the way in which they are broken doesn't affect sha1crypt or md5crypt (only a pre-image attack would break them, collisions are bad but not enough). That doesn't mean you should use them though (you should use bcrypt or similar).

I think it's relevant to GGP's use of "completely broken" - collisions are far less useful than actually extracting the password string, since one is transferable and has long-term potential, and the other will probably lose all its value pretty quickly, especially with a change of salt.

Little comfort if they weren't salted.

Absolutely not, it ties all of your information together trivially. People should just use password managers with a unique password for each website. Then you don't really about one site's bad security meaning that your security on another site is ruined (with SSO that's also an issue, you just trust the SSO provider more explicitly). You only care about whether data was accessed or modified with a particular service.

Most people (e.g not hackernews readers) only care about how easy it is. Assuming that most people would prefer to simply use existing authentication services is accurate and not remotely absolute (even if it makes some of us cringe).

Most people (e.g not hackernews readers) only care about how easy it is. Assuming that most people would prefer to simply use existing authentication services is accurate (even if it makes some of us cringe).

If gmail is your password recovery address, hacking your gmail, will give the hacker access anyway.

And if your Google or Facebook account is hacked...?

Same as if your password manager account is hacked.

There are non-cloud based password managers.

"Wish all sites reported your activity to advertisers like Facebook or Google."

Convenience is a big selling point, but the price is too high.

Single sign on is single compromise.

If your single sign on provider is also the email address for password recovery, single sign on doesn't compromise you further.