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!
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!
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...
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" ;)