Live data from Hacker News

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

blog.gitguardian.com

211–220 of 272 posts

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

#211
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.

You're not the first with this idea! There exists a standard, see RFC 8959: https://www.rfc-editor.org/rfc/rfc8959.html

Previous HN discussion: https://news.ycombinator.com/item?id=25978185

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

#212
post #204

Ah. I can’t believe this still happens in this day of age. About a decade ago, I was working for a startup and we were getting dominated in our growing space by a much larger, well funded rival. Our competitive intelligence team browsed through their git, and the rival actually exposed access to their customer, pricing and sales agent database by leaving their credentials in one of their branches. The team went to ou…

and that folks, is how you do growth hacking ;)

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

#213
post #201
post #101

Earlier quoted context omitted.

Just stick an Amazon t shirt on, a reflective yellow waistcoat and a box and you can walk into most SMEs without anyone blinking an eye. I've seen it done hundreds of times...

Is there a corresponding ISO control for this?

There probably is but ISO certs are just paperwork filed. Reality is different.

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

#214
post #148

Earlier quoted context omitted.

Yes, seriously. They need to service the vehicle, OK, but communicate to and through the vehicle.

What does that mean? The repair tech tells my car that it's ready for pickup and my car ignores him because it's a car not a communication channel?

I can tell my local repair guy down the road my number. No need for some megacorp to know who I am.

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

#215
Some time ago on devops reddit someone asked „What is the biggest vulnerability in your system?”

Most common answer was „Developers”

It do be like that. Without proper automation and processes and education of ppl involved it can get really bad.

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

#216
post #204

Ah. I can’t believe this still happens in this day of age. About a decade ago, I was working for a startup and we were getting dominated in our growing space by a much larger, well funded rival. Our competitive intelligence team browsed through their git, and the rival actually exposed access to their customer, pricing and sales agent database by leaving their credentials in one of their branches. The team went to ou…

If you're in the US, that's 100% a crime. If they were responding to an unauthenticated API or web request that's one thing, but using a leaked password on a database is not legal at all.

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

#217
post #148

Earlier quoted context omitted.

Why would they need to have > customer identification numbers and emails to provide service? Seriously?

Yes, seriously. They need to service the vehicle, OK, but communicate to and through the vehicle.

These are the services, according to the article:

“T-Connect enables features like remote starting, in-car Wi-Fi, digital key access, full control over dashboard-provided metrics, as well as a direct line to the My Toyota service app. The servers that control these options contain unique customer identification numbers and customer emails.”

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

#218

Earlier quoted context omitted.

Rant time: this isn’t directed at you. I am just replying to your comment because you said something that triggered me. Also the “you” below is the generic you - not you personally. Disclaimer: I work at AWS in Professional Services, all rants are my own. Now with that out of the way, I hate the fact that there are way too many code samples floating around on the internet that have you explicitly put your access key…

I deal with this by having a directory in my development tree, named ”doNotCheckThisIntoSourceControl” , and I add a wildcard of it to my global .gitignore. I’ll put things like server secrets and whatnot, there. Of course, I need to make sure the local directory is backed up, on this end, since it is not stored in git. Works a treat.

That’s really not a great idea…

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

#219
post #143

Earlier quoted context omitted.

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

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}.

There is already RTC 8958 Secret token scheme for this, so you do not need to invent your own prefix

https://datatracker.ietf.org/doc/html/rfc8959

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

#220

Earlier quoted context omitted.

Awesome feature. Saved the day for us some months back when an AWS token was accidentally committed and pushed. (AWS itself also immediately notified us.)

Rant time: this isn’t directed at you. I am just replying to your comment because you said something that triggered me. Also the “you” below is the generic you - not you personally. Disclaimer: I work at AWS in Professional Services, all rants are my own. Now with that out of the way, I hate the fact that there are way too many code samples floating around on the internet that have you explicitly put your access key…

> I hate the fact that there are way too many code samples floating around on the internet that have you explicitly put your access key and secret key in the initialization code for the AWS SDK.

See, I thought that was a big strength of a lot of the AWS documentation over Google Cloud.

An AWS example for, say, S3 would show you where to insert the secrets, and it would work.

The Google Cloud Storage examples, though? It didn't seem to have occurred to them that someone reading "how to create bucket example" might not have their credentials set up.

And when the example didn't work - well, it was like the auth documentation was written by a completely different team, and they'd never considered a developer might simply want to access their own account. Instead the documentation was a mess of complicated-ass use cases like your users granting your application access to their google account; sign-in-with-google for your mobile app; and so on.

Google's documentation is better than it once was - but I've always wondered how much of the dominance of AWS arose from the fact their example code actually worked.

Post reply on HN