back to article GitHub saved plaintext passwords of npm users in log files, post mortem reveals

GitHub has revealed it stored a "number of plaintext user credentials for the npm registry" in internal logs following the integration of the JavaScript package registry into GitHub's logging systems. The information came to light when the company today published the results of its investigation into April's unrelated OAuth …

  1. Pascal Monett Silver badge
    Facepalm

    GitHub stored a number of plaintext user credentials

    Oh. My. God.

    That is a major boo-boo.

    Shame on you, GitHub. You knew better than that.

    1. Version 1.0 Silver badge

      Re: GitHub stored a number of plaintext user credentials

      Oh, I was reading the story and wondering why the PFY and PHB were not being mentioned, the story is just the BOFH reality.

    2. Robert Carnegie Silver badge

      Re: GitHub stored a number of plaintext user credentials

      Well, they didn't store them, they logged them. Useful because... actually I'm not sure how. Maybe to see when a user is typing the correct password but still not getting in somehow.

  2. Duncan10101
    WTF?

    FFS

    This is basic stuff. How could they get it so wrong?

    How did it ever pass a security review?

    Or even a code review?

    It makes me sad to see stories like this.

    1. Anonymous Coward
      Anonymous Coward

      Re: FFS

      Because the developers are stupid.

      Why do you assume they performed a security review? Or a code review?

      Ditto...

  3. Plest Silver badge
    Facepalm

    One of the first lessons junior devs get pummelled into them ( or they should if their mentors are worth their salt ) is never, ever put anything in a repo you don't want to share, even private repos. Then chuck in the fact that scanning public repos is one of the standard gathering exercises that even the most basic security course will teach you how to do.

    These fact alone are standard practice and should have put Github on the offensive on all their activities.

    1. Gene Cash Silver badge

      Security course? What?

      "the most basic security course will teach"

      I don't think I've ever encountered those words in that order. In 40 years, I don't think I've ever had any formal security-in-software-development training

    2. AndrueC Silver badge
      Facepalm

      One of the first lessons junior devs get pummelled into them ( or they should if their mentors are worth their salt ) is never, ever put anything in a repo you don't want to share, even private repos.

      This is why I never swear in source code. There is a (probably apocryphal) story about a software developer who worked at a bank. While testing a mailshot he had a bit of a laugh to relieve the monotony. Unfortunately he forgot to tidy his code before he released it. Consequently the banks top 10% of clients got a letter starting:

      Dear Rich Bastard,

      ....

  4. Anonymous Coward
    Anonymous Coward

    This vindicates…

    …my approach of NOT EVER sharing credentials with a system I don't control.

    The current "best" (or rather usual) practice for continuous deployment (CD) setups such as implemented via GitLab (I don't have experience with Travis or GitHub) revolve around giving the CD server credentials to the target system where the software is to be deployed.

    No way Jose.

    So I use a pull approach* (give the target servers credentials to the CD server), which negates many of the supposed advantages of the whole so called DevOps approach, aka house of cards.

    * This doesn't prevent certain other attacks, such as tampering with the source code or the build system, for the parts that are built or archived on public servers.

    1. Anonymous Coward
      Anonymous Coward

      Re: This vindicates…

      Replying to my own comment…

      I am of course not surprised by GitHub's fail. It's a given that the tokens are stored as plain text, otherwise they wouldn't be usable, though to be honest I would have expected them to store the (plain text) tokens in some form of encrypted vault, which reduces, but does not eliminate, the attack surface, especially while at rest.

    2. Robert Carnegie Silver badge

      Re: This vindicates…

      Though at least once a week you type something else's password into a thing, anyway. Well, I do.

  5. Kevin McMurtrie Silver badge
    Meh

    Logging auth tokens passed code review? Nobody read the logs -or- people read the logs but didn't do anything about auth tokens in it?

    Should you worry about too much apathy in the company or is that somebody else's problem?

    1. Tom 38

      Some context is worthy here. Github didn't write this code, npm did. Github acquired npm, and integrated npm's software into Githubs logging infrastructure.

      npm's devs most likely wrote debug/info log statements that were only meant to be seen by the developer during tests/local development. npm's systems probably only logged at the higher log level, whilst github most likely logged at a lower log level.

      It doesn't mean its not a fuckup, but I can see how it happened. Your boss buys a company, you have to integrate the sketchy software immediately otherwise service is disrupted. I bet they are reviewing every line that came from npm now..

  6. Paul Hovnanian Silver badge
    Paris Hilton

    It's sort of like ...

    ... walking around in public with your fly unzipped. Nobody pointed and laughed or screamed, so it's probably OK.

  7. Andrew Hodgkinson

    Why is anyone surprised?

    Microsoft bought GitHub, then Microsoft bought NPM, then Microsoft integrated the two.

    We're surprised about elementary and severe security failures why, exactly?

  8. Anonymous Coward
    Anonymous Coward

    The cloud...

    Other peoples computers you have no control over.

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

Biting the hand that feeds IT © 1998–2022