Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Bug Encryption Privacy Security Software

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

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."
This discussion has been archived. No new comments can be posted.

GitHub Accidentally Exposes Some Plaintext Passwords In Its Internal Logs

Comments Filter:
  • by Opportunist ( 166417 ) on Wednesday May 02, 2018 @06:04AM (#56540466)

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

    • I guess http basic auth over TLS.
      The connection is encrypted using TLS but the password is transferred in the clear (base64).

      Don't use basic-auth.
      If you absolutely have to, use an application specific password with restricted rights.

      • Basic auth is an HTTP header, and HTTP headers are just as protected by TLS as response headers and bodies. Otherwise, HTTPS would be ineffective against Firesheep-style attacks that clone a session cookie. The other common means of authentication is submitting a password that has been entered into a field of an HTML form as part of an HTTP POST request body. What's any more "in the clear" with HTTP basic authentication than with the form route?

        And in case you believe both forms and basic authentication oug

    • by Anonymous Coward

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

      Quite easily.

      Change your form to send a GET request instead of a POST, and *blam* form contents go into the server log as part of the request URI.

      With a normal form submit, this would, of course, be noticed immediately by the user (and one would hope by the developer and QA too) because the form contents show up in the browser URL bar, but if the request is made via Ajax, then this doesn't happen so it could get missed.

      Another way it can happen is a debugging statement left in the code that dumps the user o

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

      Er, because the user clicks "submit" on a password change form? And somebody was debugging something, and was logging the submitted data before the password got hashed?

    • by art123 ( 309756 ) on Wednesday May 02, 2018 @08:27AM (#56540848)

      Every single web site you use including Slashdot, Gmail, etc etc has the plain text password available to the server. The hashing of the password with a salt runs on the server. This Github bug was simply that a developer wrote the plain text password to a log file during the authentication process. They didnâ(TM)t store the plain text password in a database.

      • by Dwedit ( 232252 )

        It makes me nervous enough that I think basic hashing and encryption should be done at the client side as well. This would stop everything that isn't tampering with the site itself.

        • by mark-t ( 151149 )

          No, it wouldn't.

          Let's say your password is X, and you hash it locally to Y. You still have to send Y to the server to be validated. There's no way around this.

          If you are sending Y, then it is possible that the server could potentially log Y, and someone who sees those logs might in turn be able reproduce your login by sending Y themselves, even without ever knowing what X is.

          That Y might happen to be a binary string that has no visible representation or ability to directly type on a keyboard has n

          • by lgw ( 121541 )

            Let's say your password is X, and you hash it locally to Y. You still have to send Y to the server to be validated. There's no way around this.

            You don't ever need to send the password, X or Y, if you can depend on running some JS on the client: just use a zero-knowledge proof of identity. However, it's pointless overkill, as man-in-the-browser attacks are more common than MITM attacks these days. Complicated login approaches don't really help against the common attack, so there's little point in getting clever - just make sure you're using HTTPS and POST not GET.

            • by mark-t ( 151149 )
              Anything that you send to the server can be read by that server and can therefore be potentially logged as plain text (which is what happened here). The only way around this is to move 100% of the server functionality to the client, which means that the client can't exchange any data with the server in any way (because any data that they do exchange to somehow confirm identity can be logged, as I said above).
              • by lgw ( 121541 )

                Yes, yes, which is why a method of authentication that is not replay-able is preferred, all things being equal. You're missing the point of "zero-information" protocols: log whatever you want, or send it in the clear, it gives an outsider zero information that's of any future use.

                • by mark-t ( 151149 )
                  It doesn't matter if you send it in the clear or if you send it encrypted... the point is that the server will know what you sent, and if that server logs what you sent, then all someone else will have to do is send the same thing in their own session. If you can't replicate it, then there's no way for the server to possibly be able to verify your identity at all.
                  • by lgw ( 121541 )

                    Protip: when you don't understand the words being used in the post you're responding to, you might develop the habit of looking them up, [wikipedia.org] rather than continuing to demonstrate your ignorance.

                    FFS, at least understand what a replay attack is, and what a non-replay-able protocol is, before wittering on about them.

                    • by mark-t ( 151149 )

                      Second protip, don't move the goalposts of a discussion and then try and call someone on not knowing what they are talking about.

                      The suggestion above was to encrypt the password on the client side.... but of course, you still need to actually send that encrypted password, and that encrypted password could be logged. The server would never know the "real" underlying password, but a person who viewed that log could send that exact same byte sequence without ever ever knowing the alleged real password, ju

                    • by lgw ( 121541 )

                      C'mon, you said "there's no way around this", and I just pointed out "yes, there is a way around this", where it would be safe to log whatever. And if you were using JS to hash client-side, you could just do it the right way instead.

                      If you really want to solve this kind of problem with client-side JS, you can indeed solve it that way, and make it safe to log everything sent. I think that's solving the wrong problem, but you could.

          • The point isn't to prevent the server/company from getting your hash, but to make that hash useless to other third parties if it gets leaked. If you sent a hash to GitHub and GitHub inadvertently logged it, well, they had your hash to begin with so it's not any extra information, and if it gets leaked, well, at least the third parties don't have your password.

            Wouldn't this work?

            Server stores a salted hash based on username + password.

            Client sends a salted hash based on username + password.

            Server checks salt

            • by mark-t ( 151149 )
              My point is that if you are sending the server the hash then effectively, that hash *IS* your password... and that's all that a would be attacker would ever have to send to impersonate you, because that's all that *YOU* sent to identify yourself.
    • How do you think they both check your password and allow you to change your password without ever having the clear text password available?

      It's a trivial thing to do, by not thinking what you are doing through. For example, "Hey Bob, can you work on bug 127654 the "password reset fails in this obscure case" one?". Bob then adds "log(form.getAll().toPrettyString())" to the reset code and either leaves in his debugging output when he checks in the actual fix or modifies production directory if it's a cowboy d

      • By sending them a hash of the password I enter, which is then stored as a hash of that hash in their database. The idea is that even if I am the average dumb user that reuses the same password over and over, the salted hash ensures that this password is not published even if the first hash gets published (or logged, as in this case), while the second hashing ensures that knowing that first hash does not immediately compromise the authentication process.

        • So both requiring running javascript on the browser to login and not actually providing any additional security for them (the hash is now the clear text password).

          So to protect people who reuse passwords we prevent people who don't want to run javascript from logging in at all? Those people being protected could just use their own software to get the same effect without stopping non-js users from accessing the site at all.

          • You could simply allow people not wanting to run Javascript to transmit their plaintext passwords.

            Though that also eliminates any and all grounds for complaining if their true and tried and often reused "password1234!" appears in a log...

        • A string of 32 random hexadecimal digits is stronger than "password123", but it's weaker than a strong password.
    • by Junta ( 36770 )

      Generally speaking, if a scheme means the server is never handed the password at all, then a compromise of their database leaks a viable set of credentials to use to log into their service. The alternative to one-way hashing, with password provided to validate knowledge of the password is generally some variation of shared secret, where the server must have the same knowledge the client has. It may be a secret derived from the password and thus the password is still not known, but it's of small comfort wh

    • by fsck! ( 98098 )

      It sounds like the logs in question were of the form fields being submitted by the user password reset form. Even if you're using SSL (which they are) and the passwords are only stored as a hash (which it sounds like is true at GitHub), there's still a moment where the server has the plaintext password. Some logging frameworks will automatically omit or redact the value of any field like `secret` or `password`. Perhaps in this case they forgot to also redact `password_confirmation` or something.

    • I worry about this, but I see it far too often. We learned decades ago with Unix to never store the plaintext password anywhere. Instead you store a value derived in some from the password and other information (such as a secure hash function). That way even if you get a glance at the password file you never see the passwords. It's basic freshman level security.

      That a web site even has a plain text password is bad, that it stores the password is even more bizarre.

      Sadly, I think there are major tools that

    • Seen this happen a zillion times... person enters password in the "Username: " field.
      Eg (synthesised, from memory):

      Failed login for "secret" on tty04
      Successful login by "jbloggs" on tty04

  • Password reset (Score:4, Insightful)

    by gringer ( 252588 ) on Wednesday May 02, 2018 @06:10AM (#56540482)

    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?

  • OK, that's naughty and needs fixing, but it's internal logs, did it need a slashdot story?

  • 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

    Is 27 million a small number?..

  • Logging a password is a beginner's mistake, like SQL injection. I found the same bug in unreleased code many years back, and raised it to management so we could track down the engineer who did it. It's the kind of (cough) mistake that can be the "straw that broke the camel's back" when dealing with an engineer who has (cough) "negative productivity."

    Ideally, this kind of bug should be caught in code reviews. As someone who reviews a lot of code, even I'll admit that it's possible for something like this to

  • I got the email.

    I was impressed that it was handled quickly.

    I'm even more confident because I actually use a proper password manager making sure I have unique passwd's for everything.

  • I give them credit -- here they found their own security issue before it became a breach, they fixed it, and they didn't sweep it under the rug but instead they notified their users. Kudos for being forthcoming.
  • "It's unclear exactly how this bug occurred"... riiiiiiiight, git blame?

A CONS is an object which cares. -- Bernie Greenberg.

Working...