Slashdot Mirror
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."
How can a clear text password be available to them at all to record it in a log?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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?
Ask me about repetitive DNA
you feed the string and the salt into an encryption algorythm like sha512 which produces a HASH this is what gets stored
Argh!
No!
NO!!!
NO-NO-NO-NO!!!!
DO NOT USE HASHES ! (like Sha512).
These are designed to be *fast* (1), meaning that it could be not impossible for an attacker to guess the password out of the hash simply by brute forcing all the most common password and variations thereof into the same salt and see if they match.
(1 - And remember that the "tera hash" that ASIC bitcoinminer are reporting are exactly that : trillion of SHA256-like computation per second.)
USE KEY-DERIVATION FUNCTIONS (KDF) INSTEAD !
Like the Bcrypt use by github as mentionned in the summary. Or Scrypt (same used by tarsnap). Or Argon2. etc.
These also produce a value out of a password and a salt, but they are on purpose extremely slow (E.g.: by repeating a hash function over and over for a high number of iteration).
If each computation takes some time, it doesn't impact login that much (After all, you only need to log in once at the beginning of your session), but it hinders anyone wanting to brute force your password out of a stolen hash.
It makes data breaches that managed to steal your user database a lot less dangerous (because once you have successfully guessed the password from the hash, the next step is to see all the other places where the user has re-used the same password).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
So how is this "random salt" recovered when you need to check the password's validity?
It's stored along in the data base.
Most stored password have a form like :
${type of algorithm used}${parameters used}${data}
where:
- "type of the algorithm used" tell you what was used to generate this (e.g: using Bcrypt, like GitHub as mentioned in the summary).
- "data" is the actual salted-output that you need to replicate to successfully log-in
- "parameters" is any extra-data that the algorithm needs to generate password checks.
Like the salt.
Or like the number of iterations. Because nobody sane actually use a hash function such as SHA512 anymore. Instead you use a Key Derivation Function (KDF) such as Bcrypt (or Scrypt or Argon2) and those are *slow* on purpose, to make brute-forcing much less likely (e.g.: they slow down by repeating a hash for large number of iterations).
The exact implementation vary (the above is typically used by the "crypt" function used, e.g., on Linux log-ins),
but basically are the same : the salt (and iterations) are stored together with the "hash" that you need to test.
And most of the KDF function can work as "hash_to_compare = KDF(password_login_attempt, old_hash_from_database)", ie.: they can automatically extract the parameters if you give them the string that is in the database, and generate the hash the exact same way.
They'll invent a new salt (and guess the optimal number of iterations) only if you omit the old hash and give the new password as the single parameter.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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.
I am TheRaven on Soylent News