Live data from Hacker News

Toyota suffered a data breach by accidentally exposing a secret key on GitHub

blog.gitguardian.com

121–130 of 272 posts

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#121

Earlier quoted context omitted.

I actually had something similar happen to me last month. I accidentally published a discord API key to GitHub and within minutes I got a nice message from “Safety Jim” to my personal discord account letting me know they’ve found my key on a public repo and have gone ahead and revoked it. I felt like a bit of a dope but it was neat to have it happen to me. Lesson learned for sure.

GitHub PM here. Glad that was a good experience! We work with ~50 partners (details in the link below) to notify them when tokens for their service are exposed in public repos, so that they can notify you. https://docs.github.com/en/code-security/secret-scanning/sec...

That's attention to detail right there. Very nice.

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#122
post #45

Most of these (even sometimes expensive) tools only look at repos and users who are associated with the company’s GitHub org, which barely solves the problem. The much harder problem is the number of corporate secrets that are on random repositories (personal dotfiles, automations, data science scripts, etc.) across GitHub with no strong relationship to the organization. Try using GitHub Code Search to find all the F…

GitGuardian actually does this, it monitors an extended perimeter of devs and their personal/open-source repos for corporate secrets or keywords – https://www.gitguardian.com/monitor-public-github-for-secret...

Yeah, because as an employee what I totally want is my employer to monitor my every digital move outside of work!

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#123

Earlier quoted context omitted.

GitHub PM here. Glad that was a good experience! We work with ~50 partners (details in the link below) to notify them when tokens for their service are exposed in public repos, so that they can notify you. https://docs.github.com/en/code-security/secret-scanning/sec...

I wish I could set this up to block pushes proactively instead of reacting to pushed secrets.

This exists on GitHub but is not free.

https://docs.github.com/en/enterprise-cloud@latest/code-secu...

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#124
post #44

Earlier quoted context omitted.

"fun" fact - there could potentially be thousands of deaths attributed to Drs simply not washing their hands. IIRC they even basically got some hospital admin fired for creating a hand washing mandate, despite it being proven to save lives. https://www.npr.org/sections/health-shots/2015/01/12/3756639... (talking centuries ago, but maybe even today) Looks like its still a "recent" issue, lol https://www.nytimes.com/20…

That further improves the analogy. Even though we all agree washing hands is important and saves lives, it still doesn't happen on occasion.

It does, but it also suggests that there is no easy fix.

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#125
post #36
post #9

Earlier quoted context omitted.

Oh yes this. It's so easy to critically fuck up an invite into an organisation. If you get typo the username you are potentially compromised. I've seen a couple of near misses on this already. Note: the invite input box actually autocompletes ALL github usernames.

You can invite by email addr, so the workaround here is only invite corporate email addresses. If the target user hasn't added their corp email to their profile then they can't be part of the org.

This can be vulnerable to "ticket trick" - often support/helpdesk sites are put on the main domain and have reply-to email addresses that will reflect the content back to the user requesting support. This can be used to sign up for slack, etc.

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#126

Was this title re-written? I feel it was phrased more vaguely when I first read it, but I could be wrong... More curious about if that's a thing hackerNews does.

It was "Toyota Accidently Exposed a Secret Key Publicly on GitHub for Five Years".

Thank you https://hackernewstitles.netlify.app/

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#127

Earlier quoted context omitted.

GitHub PM here. Glad that was a good experience! We work with ~50 partners (details in the link below) to notify them when tokens for their service are exposed in public repos, so that they can notify you. https://docs.github.com/en/code-security/secret-scanning/sec...

I wish I could set this up to block pushes proactively instead of reacting to pushed secrets.

Yelp has a "detect-secrets" project that can detect potential secrets and can be used as a pre-commit hook: https://github.com/Yelp/detect-secrets

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#128
post #113

Earlier quoted context omitted.

How would you update the keys every 5 min? Either you'd use an encryption algorithm that depended on a "deeper" key... or you'd fetch the new key while authenticated with, you guessed it, another "deeper" key. It's keys all the way down. Every key you use, it's your responsibility to keep it private. (Unless you want to be dealing with physical hardware dongles that generate keys, but those aren't exactly easily port…

Not exactly the same but I had to integrate with a payments API which required one call to an auth endpoint with user/password under HTTP basic auth to get an access token. The actual calls to calculate and execute payments used this access token instead as a bearer token. Those ones expired. I'm not sure I really see the point, but I guess you could lock down the main call on another system, store the temporary toke…

Yah, that's the OAuth Client Credentials flow but as noted, you still have a static set of creds that are required to generate the short lived access token. Besides being useful for being able to limit scope in some circumstances, the main point of the client cred flow is to appease eager sec arch's who insist on OAuth.

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#129
post #102

Earlier quoted context omitted.

Is this really expensive? We're a small startup providing API keys, to our customers.

It's totally free - there are details of how to join the program at https://docs.github.com/en/developers/overview/secret-scanni...

Hm - this would work better if keys were easy to scan with regular expressions.

Next time I implement api keys I wonder if it’s worth going out of my way to make them easy to identify. Eg, by prefixing every key with a few well known characters. Like FMLA_xxxxx for a fastmail app key.

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#130

Earlier quoted context omitted.

I actually had something similar happen to me last month. I accidentally published a discord API key to GitHub and within minutes I got a nice message from “Safety Jim” to my personal discord account letting me know they’ve found my key on a public repo and have gone ahead and revoked it. I felt like a bit of a dope but it was neat to have it happen to me. Lesson learned for sure.

GitHub PM here. Glad that was a good experience! We work with ~50 partners (details in the link below) to notify them when tokens for their service are exposed in public repos, so that they can notify you. https://docs.github.com/en/code-security/secret-scanning/sec...

[deleted]
Post reply on HN