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 ..."
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 …
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.
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.
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.
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.
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?
Biting the hand that feeds IT © 1998–2019