4 ms·

Did I miss the previous GitHub announcements about this amidst all the noise about how badly Heroku handled their part of this problem? Or have GitHub been sitt

Did I miss the previous GitHub announcements about this amidst all the noise about how badly Heroku handled their part of this problem? Or have GitHub been sitting on the specific facts they had a database, email, and hash passwords leaked for over a month now?

tln 4y ago
TFA starts with "On April 15, we published a blog[0] detailing an attack campaign ..." So, there was a blog post on April 15, at least. [0] https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/ https://github.blog/2022-04-15-security-alert-stolen-oauth-u...
- glenngillen 4y ago
  Yeah, that’s the only one I recalled seeing. And nothing at the time of a database leak with emails and hashed passwords, nor a backup that included access to private repos.
ralph84 4y ago
I take it you’ve never been involved in a breach investigation. Figuring out what an attacker had access to and whether they exploited that access isn’t trivial, especially for a heavily used service like npm. To say they were “sitting on” information while probably tens if not hundreds of engineers assisted in making sure the investigation was complete and accurate is uncharitable.
- glenngillen 4y ago
  How presumptuous. I’ve worked with all of the teams involved in this specific incident over the past 12 years. I’ve helped lead incident response for much larger breaches. I know what’s involved. And the moment you’re aware customers have had their passwords exposed (even if hashed) you come clean on it and empower them to take mitigating action so that they’re not unduly exposed longer than they need to be. You probably even consider forcing password resets for everyone. As Heroku did, in its own hamfisted and still too slow way.
  - ralph84 4y ago
    And you know the exact moment GitHub became aware that passwords were exposed and that they "sat on" that information? If you actually did work with those people, that's even more reason to assume good faith. Saying "I could have done it better" isn't helpful.

tln 4y ago

TFA starts with "On April 15, we published a blog[0] detailing an attack campaign ..." So, there was a blog post on April 15, at least. [0] https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/ https://github.blog/2022-04-15-security-alert-stolen-oauth-u...

glenngillen 4y ago
Yeah, that’s the only one I recalled seeing. And nothing at the time of a database leak with emails and hashed passwords, nor a backup that included access to private repos.

ralph84 4y ago

I take it you’ve never been involved in a breach investigation. Figuring out what an attacker had access to and whether they exploited that access isn’t trivial, especially for a heavily used service like npm. To say they were “sitting on” information while probably tens if not hundreds of engineers assisted in making sure the investigation was complete and accurate is uncharitable.

glenngillen 4y ago
How presumptuous. I’ve worked with all of the teams involved in this specific incident over the past 12 years. I’ve helped lead incident response for much larger breaches. I know what’s involved. And the moment you’re aware customers have had their passwords exposed (even if hashed) you come clean on it and empower them to take mitigating action so that they’re not unduly exposed longer than they need to be. You probably even consider forcing password resets for everyone. As Heroku did, in its own hamfisted and still too slow way.
- ralph84 4y ago
  And you know the exact moment GitHub became aware that passwords were exposed and that they "sat on" that information? If you actually did work with those people, that's even more reason to assume good faith. Saying "I could have done it better" isn't helpful.