Live data from Hacker News

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

blog.gitguardian.com

201–210 of 272 posts

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

#201
post #101
post #96

Earlier quoted context omitted.

Everyone complains about post-it notes, but the physical proximity requirement to read them isn't nothing. E.g. compared to network-accessible files. At least, until you have a network-attached webcam pointed at your whiteboard. But the solution to the webcam problem is to write its access credentials on your whiteboard, thus forming a circular and perfectly secure loop.

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?

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

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

> Note: the invite input box actually autocompletes ALL github usernames. I'm sorry, but that's wild. That's like, not even an easy engineering problem to solve necessarily, given their size!

Sorry, but string prefix search over a few hundred million entries is something you can do with the same performance using just postgres on a single server with just a few hours of dev time.

I've done it before, it's not as impressive as it seems.

With trigrams you can even do precise substring search on this scale with good performance.

If you'd like, I can build a small demo.

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

#203
post #89

Question: Let's say I want to open source my app but a long time ago I used to have credentials hard coded. What can I do to clean this up from history?

Here's a checklist [1] (again, from gitguardian) of steps to follow before open-sourcing projects and [2] a guide on how to remediate hardcoded/exposed secrets.

[1] https://blog.gitguardian.com/safely-open-source-software-bes... [2] https://blog.gitguardian.com/leaking-secrets-on-github-what-...

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

#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 our legal department asking if they can be protected by the company, and if they can use this intel. The team then worked with the product team to integrate all their pricing engines to our POS to undercut their pricing and sent marketing blasts to their leads with targeted marketing campaigns. Long story short that company is now defunct, and it definitely undermined their growth.

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

#206
I used to report things like this that I had found, including cases where I can see people used the default "sample" config for security purposes, but I found that either people would not care at all, or massively overreact and somehow blame me.

If an organisation is disorganised enough to leave critical details in public, they're probably too disorganised to handle someone reporting it.

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

#207

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

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

#208
post #143

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

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

I don't think it's a regex pattern, most keys are random strings.

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

#209
post #198

Earlier quoted context omitted.

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.

I think prod_ might not be the important part there, so something like __secret__ should be enough.

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

#210
post #181

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

Would blocking commits containing such tokens/keys be a better option?

This is what I do[0]. Low-tech and un-sexy, but WFM. YMMV.

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

Post reply on HN