Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.gitguardian.com

Post reply on HN
Print view View original

191–200 of 272 posts

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

#191

Post by gl-prod »

rytis wrote: post #175
gl-prod wrote: post #170

Earlier quoted context omitted.

Yeah, prefixing your keys with your service name like SRVCE_{KEY} is the way to go. Bonus: adding SRVCE_PRVT_{KEY} and SRVCE_PUB_{KEY}.

And while we're at it, I think saving two chars isn't going to do much to prevent global warming, and let's just use more readable SERVICE_{KEY} and SERVICE_PUB_{KEY} (as opposed to having scratch your head thinking "did I call it SRV, SVC, SRVC, SRVCE, ...?")

I meant as an abbreviation, like GitHub becomes ghp_XXXXXXXXX. But yeah anything is better than just random characters.

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

#193

Post by atoav »

Github is amazing. Wanna get expensive licensed fonts for free? Just search for $FONTNAME.otf github and you will find at least a few projects using it.

People don't think a lot about what they put on there it seems. Or maybe font foundaries haven't sued enough at this point.

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

#194

Post by josephg »

nmjenkins wrote: post #164
josephg wrote: post #129

Earlier quoted context omitted.

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.

If you go make an API key in Fastmail (Settings -> Password & Security -> API tokens), you'll see that it's prefixed very similarly to that (e.g. `fmo1-`) for this very reason! (There are some other neat things about our API key format I'd be happy to tell you about sometime if you're interested.)

Hah I just used that as the first example which came to mind.

Yeah absolutely - I'd love to hear about it!

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

#195

Post by Paul_S »

I worked for a couple corps in my life and the security theatre in here is ridiculous. At the same time things like this happen all the freaking time. And none of the company spyware can catch that. Funny how this never happened in small companies I worked for, although maybe that's just a function of number of people? Or maybe because small companies rely on fewer platforms and frameworks so fewer chances of such leaks?

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

#196

Post by withinboredom »

Paul_S wrote: post #195

I worked for a couple corps in my life and the security theatre in here is ridiculous. At the same time things like this happen all the freaking time. And none of the company spyware can catch that. Funny how this never happened in small companies I worked for, although maybe that's just a function of number of people? Or maybe because small companies rely on fewer platforms and frameworks so fewer chances of such le…

In my experience, smaller companies tend to hire the best they can attract and afford. Larger companies tend to collect talent so no one else can get it, so it usually isn't "the best."

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

#197

Post by isolli »

Reminds me of a related HN discussion a few years ago: someone searched for "remove password" in GitHub and unearthed who knows how many valid passwords in the hundreds of thousands of commits that the search returned...

[0] https://news.ycombinator.com/item?id=13650818

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

#198

Post by jve »

echelon wrote: post #168
comboy wrote: post #143

Earlier quoted context omitted.

TIL: make private key for your service easy to match with regexps

The whole industry should adopt a convention to prefix production keys with a well known prefix, such as "prod_secret_". We should have our systems and precommit hooks then alert us when those enter places they shouldn't and help us automate rotation.

Bad idea. Better do it in DEV like you would do in PROD, not to shoot yourself in the foot. If you do it right in DEV, no problem in PROD.

And what if your DEV is not actually well isolated from PROD/other infra? And what if some real data sneaked into DEV? Etc.

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

#199

Post by hawski »

rytis wrote: post #175
gl-prod wrote: post #170

Earlier quoted context omitted.

Yeah, prefixing your keys with your service name like SRVCE_{KEY} is the way to go. Bonus: adding SRVCE_PRVT_{KEY} and SRVCE_PUB_{KEY}.

And while we're at it, I think saving two chars isn't going to do much to prevent global warming, and let's just use more readable SERVICE_{KEY} and SERVICE_PUB_{KEY} (as opposed to having scratch your head thinking "did I call it SRV, SVC, SRVC, SRVCE, ...?")

I think OP meant to use the actual name of the service. For example FOOBARINC_{KEY}

I also think that it should look just a bit cryptic to make a person unsure if they can meddle with the string.

Post reply on HN