GitHub Accidentally Exposes Some Plaintext Passwords In Its Internal Logs (zdnet.com)

GitHub has sent an email to some of its 27 million users alerting them of a bug that exposed some user passwords in plaintext. "During the course of regular auditing, GitHub discovered that a recently introduced bug exposed a small number of users' passwords to our internal logging system," said the email. "We have corrected this, but you'll need to reset your password to regain access to your account." ZDNet reports: The email said that a handful of GitHub staff could have seen those passwords -- and that it's "unlikely" that any GitHub staff accessed the site's internal logs. It's unclear exactly how this bug occurred. GitHub's explanation was that it stores user passwords with bcrypt, a stronger password hashing algorithm, but that the bug "resulted in our secure internal logs recording plaintext user passwords when users initiated a password reset." "Rest assured, these passwords were not accessible to the public or other GitHub users at any time," the email said. GitHub said it "has not been hacked or compromised in any way."

Comments

Umm... how's this possible?

[Opportunist]

How can a clear text password be available to them at all to record it in a log?

Re:Umm... how's this possible?

[Opportunist]

What should happen is that a hash gets calculated on client AND server side, you don't want to store the client's hash directly in the database... for obvious reasons.

Re:Umm... how's this possible?

[TheRaven64]

If you hash on the client, then you're not really hashing, you're just using a different password and the thing in your database is now the real password, because that's what the client presents to log in. If you really want to do it properly, there are zero-knowledge protocols that allow it, but simply hashing on the client is not sufficient.

Password reset

[gringer]

the bug "resulted in our secure internal logs recording plaintext user passwords when users initiated a password reset."

...

"We have corrected this, but you'll need to reset your password to regain access to your account."

Er... are you really sure that this has been corrected?

Re:How did this happen?

[TheRaven64]

The salt isn't secret, it's just used to prevent rainbow tables from being useful. If you store passwords as unsalted hashes, then an attacker can construct a large table of all of the hashes of 8-character inputs and compare each of your hashes against their table. If there's a match, then they have a password that will work. If you add a salt, then they can't use such a table, because they have to check each 8-character sequence with the hash prepended. If the salt is different for each password (as it should be), then there's no benefit from pre-calculating the table. If it takes 2 hours of GPU time to compute the table, then with unsalted passwords that's a one-time cost and you can then crack any weak password in a leaked password database almost instantly. In contrast, it will take you 2 hours to attempt each password and crack each weak one in a leaked salted password database.