💩 Secret Story from Michael-206

I had a moment of brilliance and decided to play "Hide and Seek" with my mail credentials and even tossed in some public router credentials for fun. But, oh boy, GitGuardian crashed the party and ratted me out! Thanks to its watchful eye, I quickly evicted those secrets and upgraded the locks. Phew, crisis averted!

‍

Worked for an incredibly large and popular IDE with millions of dollars in investors. The number of times that source maps were accidentally pushed to prod *and* that people downloaded them. Yikers.

I added all my top-secret credentials and API keys to my application.properties files and pushed them to my private git repository. Now I'm on a mission to renew all of them without causing any chaos or destruction!

Many years ago, I used AWS for a bootcamp project. At this point, I was midway through it and scrambling to finish the rest, so I was in a rush and working on this at 3 AM.

I unknowingly committed and pushed my credentials to GitHub, then went to bed. The first clue I had that anything was wrong was an email from AWS the next morning. I checked my account and saw that there was over $1500 in charges.

I had to step out of class for about an hour to chat with a rep to sort everything out. So on top of making a silly mistake and speaking a significant amount of time remediating it, I had to explain to the instructors why I was gone for so long.

This incident then became a cautionary tale for subsequent cohorts. If I had to learn this lesson the hard way, I’m glad it was when the stakes were low.

There is no fun in leaked secrets. Get back to work!

Forgot to encrypt the bucket stored on public cloud. Realized when I noticed dozens of notifications that my links were accessed.

From onprem to cloud migration. Lets get the source code in gitlab. Everything fine and dandy, but after 3 weeks we get pull requests with "nice your keys in here" and they added rickrolling to our code! Rickrolling at the workplace for a few hours. We fixed it, and the hackers our Britney hit one more time back from us!

I was TA for a Computer Science course at University. I wrote a program to help us easier manager our cloud infrastructure and stored it in the department's GitHub organization.

To make it easy for other TAs to use, I included plaintext credentials in the repo. Three weeks into the quarter, a student informed us that they could access our repo... and thus the credentials, giving them access to all our infra and answer keys.

Thankfully, it appears that no one used the creds, we hurriedly had to refresh the keys and I had to rewrite a lot of exam question. ¯\_(ツ)_/¯

It is best I learned this lesson in a low-stakes academic environment instead of on a real-world system.

My favorite story is probably a traumatic experience that I still laugh at today.

Back when I was an intern at another company, my second day on the job in infosec there was a news report that the Navy was hacked. My manager, wanting to see my researching skills, wanted me to investigate how it happened.

Long story short, the navy was hacked by a smart sex toy and the first week on the job as an intern I had to present to a panel of my peers, mentors, managers, and senior executives the importance of IoT security because devices like smart sex toys from China have default passwords that can be hacked to then steal data of a secret navy base because of a contractor that needed some relief.

I'm still embarrassed to this day, but they liked my report!

Well, a typical story of a temporary hardcoded solution, which got pushed to git and exposed everything for hell a lot longer time than it was originally expected.

We had all of the financials for the year package into a unencrypted zip file and put it up on our website by mistake.

Luckily we noticed it the next day and took it down. Thankfully nobody downloaded it.

In the project where we were working, our idea was to have a separate server where to store the secret keys.

In order to maintain fault tolerance, we decided to keep a backup copy of the secret keys in some of the cloud providers.

We had the problem when we needed to use one of these copies and check how the keys were not the same since the synchronization between our server and the cloud provider had been lost.

From the point of view of maintaining the same data, it would have been important that the information is synchronized between both servers.

I'm a developer working on a site called ProjectDirect and let me tell you the one time I pushed my code to GitHub and realized that I had hardcoded my SMTP credentials right into the codebase. Talk about a rookie mistake!

As soon as GitGuardian alerted me of the blunder I immediately sprang into action and did the only logical thing: I deleted the entire repository and started over from scratch. Crisis averted!

Now if you'll excuse me, I have to go burn all of my copies of "Code for Dummies" before anyone else finds out about my epic fail.

‍

I was working on building a docker image in a new repo & needed it to be pushed to Dockerhub.

When I was happy with my Dockerfile, I ran `git add .` & pushed everything to my public github repo.
‍
Unfortunately, I hadn't added a .gitignore file to the repo, so my .env was committed to Github, along with my Dockerhub credentials.

I spent my friday evening ensuring my Dockerhub account was not tampered with. So that was fun...

Due to config errors the secrets got shared internally and they became "open secrets".

Everyone knows but they are secrets.

Many moons ago, I worked for the tasty Whataburger Corporation in Texas ... you know ... the WHAT-A-BURGER place!

Anyways, I was doing IT maintenance on the system. I was reconfiguring the AS400 backup tapes (ancient I know) and when I configured the backup, I accidentally used the delete code in our SOP that was right next to the instructions to restore. So all of our payroll data got deleted. Trying to figure out how to restore, I posted our information to Github with our private IP addresses, server names, and all.

We ended up calling IBM to fix the AS400, had to remove my Github post and ended up getting written up. ALWAYS DOUBLE CHECK YOUR WORK!

What made this funny is that around this time is when Snowden did his thing, so I was called the What-A-Shame Snowden! (in good fun of course). Yeah it wasn't pretty.

Well, my story of leaked credentials is not very funny, at least not for my employer... :)

I started to use a github action (actions-aws-ssm-params-to-env) inside our workflow and I didn't check for credential leaks.

After a lot of workflow runs, my employer noticed that in the workflow log there were our AWS credentials in plain text!! :O

You know, after that we had to create other AWS credentials for all our environments, because the workflow was already used in all our development/demo/production branches.

A GitGuardian webinar helped me create a checklist of stuff to check before considering a workflow "safe" ;)

My Story about Leaked Credentials.

It was when I started learning Python, I was so fascinated about how everything works that I wanted to try sending emails with Python.

I went through some tutorials on Youtube read through some books and finally got how to do it.

I changed the privacy settings on my Google Account and proceed with writing the scripts, everything was done and I could send multiple automated emails to different people.

I then proceed to share the code with my friends by pushing it to Github, I pushed it to Github with my password as a variable.

I sent the link to one of my friends and he messaged me back, not immediately, that he has my G-mail address and password.

I was confused and later begged him to tell me how he got it. That was when I knew I pushed my password to Github, embarassed.

I quickly had to change the password and deleted the repository.

A coworker of mine, after some restructuring of env files and how they are loaded, commited an env file that was supposed to be ignored, with all the credentials for multiple integrations - postmark, db passwords, algolia keys, you name it

{{authorHandle}} | {{authorCompany}}

Tell us your story (make it fun & short 🙃)*

Authorization*

What name should we use for your story?

Best Secret Stories