back to article GitHub flub spaffs 8Tracks database, 18 million accounts leaked

A staffer of social music streaming site 8Tracks is having a really bad day: a bit of GitHub user carelessness has leaked 18 million accounts. The good news: the service assures users that passwords in the database were salted and hashed – however, the usual “don't re-use passwords” still applies. People who signed up to …

  1. frank ly

    It's a long slow process

    "... it found backups of database tables in the staffer's repo."

    I assume/hope that will be covered by this:

    "We are auditing all our security practices ..."

    1. Anonymous Coward
      Anonymous Coward

      Re: It's a long slow process

      I would not be sure they understand storing production data in an internet facing development VCS, not exactly designed to be a strong vault, is a bad idea...

      Also, hope the salt was not in the same repository....

      1. Korev Silver badge
        Coat

        Re: It's a long slow process

        Quite, otherwise there will be an assalt on those passwords...

      2. MJB7

        Also, hope the salt was not in the same repository....

        That shows a *profound* misunderstand of what "salting" means. The salt is stored in the database along with the hashed password. It is not, in any way, intended to be secret.

        The point is that different users will have different salts, and what is stored in the database is the hash of the salt+password. This means that the attacker must try common passwords for each individual user (well, individual salt), and can't just hash all the common passwords once, and then look up each user's hashed password in that list.

        1. ArrZarr Silver badge

          Re: Also, hope the salt was not in the same repository....

          However, if the salt wasn't included in the repository, it would make the would be hacker's job even harder, would it not?

        2. Sgt_Oddball

          Re: Also, hope the salt was not in the same repository....

          This is why I er towards adding external pepper too.

          1. DropBear

            Re: Also, hope the salt was not in the same repository....

            That is a very oddball suggestion, Sgt_Pepper - I would not expect it to slow down the Blue Meanies at all...

        3. a_a

          Re: Also, hope the salt was not in the same repository....

          That shows a *profound* misunderstand of what "salting" means.

          That shows a *complete* failure to read the article:

          and on investigation it found backups of database tables in the staffer's repo.

        4. Anonymous Coward
          Anonymous Coward

          Re: Also, hope the salt was not in the same repository....

          If you know the salt for each hash, and the hash rounds, you can still build tables to recover the passwords.... especially if you spot some interesting user names (i.e. admin....) and decide to crack only those passwords.

          Thereby putting the hashing code, the salt and the production hashes in the same repository is quite stupid.

  2. Korev Silver badge

    Lesser of two evils?

    People who signed up to 8Tracks via Google or Facebook aren't affected.

    I'm always in two minds about using {Facebook,Google}-based authentication. I hate giving them this much power; however, I trust them more not to **** up than a random developer like in this case.

    1. Toc-H-Lamp

      Re: Lesser of two evils?

      But in next to no time they will have dropped down the scale of current tech companies and will leak like a sieve. Think of Yahoo.

    2. Ian Michael Gumby
      Boffin

      @Korev Re: Lesser of two evils?

      I hate giving them this much power;

      Then don't.

      Just to be safe, I went to Github, set up 2 factor authentication and then changed my password.

  3. thosrtanner
    Unhappy

    github flub?

    I thought for a moment from the headline that github was leaking passwords. But it seems it's not github at all.

    It's not really githubs fault that someone put things there they shouldn't have done (or at least shouldn't have done without more security). The whole point of github is for people to read and share information.

    I think this article could do with a little bit of retitling / rewording.

  4. Anonymous Coward
    Anonymous Coward

    Time to mandate random passes and password managers?

    Is it time to choose an option where we assume the password/account name will leak for each and every site? So the only solutions will be those that work WITH leaks being an assumed risk?

  5. breakfast Silver badge
    WTF?

    To me the big question is why the content of the database was ever on Github. Structure, sure, I get that. But the records inside?

    1. Donkey Molestor X

      > To me the big question is why the content of the database was ever on Github. Structure, sure, I get that. But the records inside?

      I'm guessing that the dev got complacent and started treating a remote repo like a personal disk volume.

      1. Robert Helpmann??
        Facepalm

        I'm guessing that the dev got complacent and started treating a remote repo like a personal disk volume.

        You had me at "complacent".

    2. JimmyPage Silver badge
      FAIL

      My theory is the developer(s) in question didn't really grasp how GitHub works, and managed to include the database in the files uploaded.

      Which suggests they were developing against an unscrambled copy of a live database.

      FFS, 15 years ago, it was compulsory to scramble data when taking a cut of live for dev or test. Of course all that (highly paid) experience has been let go, so we have kids in charge.

      I really fear for the *next* 15 years.

  6. Jeff 11

    As the company explains in its fess-up post, the source of the leak was an inadequately-secured GitHub repository: an employee wasn't using two-factor authentication. 8Tracks found out when there was an unauthorised attempt at a password change, and on investigation it found backups of database tables in the staffer's repo.

    The source of the leak was storing backups in source control on a public service, and inadequate access controls - either allowing devs access to production data or ops to source control! How does 2-factor auth address that?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like