Someone at my company generated the keys. They then put them on a network share without any security restrictions. They've been there for 5 years with no rotation. At least 2 are checked into source control.
The company solved this by giving me a root username and password that worked on every single important database in the company, at least every customer database.
I had to beg them to create a somewhat restricted account.
The same company was however deeply sceptical to all kinds of remote work. The security equivalent of penny wise pound foolish I guess :-]
If they slack off, at least they do it in the office and not freely at home (imagine the possibilities!)
To keep the charade up I sent one of every 20 requests to them to do for me.
But we aren't allowed internet access on our workstations because "security"
I wish you the energy to keep trying to change this, don't let it get to you too much, I know this stuff can be frustrating as hell.
There are multiple automated systems that scan public repos for credentials. 5 minutes later you are mining bitcoins for them.
> When you push to a public repository, GitHub scans the content of the commits for secrets. If you switch a private repository to public, GitHub scans the entire repository for secrets.
> When secret scanning detects a set of credentials, we notify the service provider who issued the secret. The service provider validates the credential and then decides whether they should revoke the secret, issue a new secret, or reach out to you directly, which will depend on the associated risks to you or the service provider.
https://help.github.com/en/github/administering-a-repository...
Not particularly germane to the discussion, but really disappointed in how SendGrid handled things. I notified them immediately, rotated all API tokens, and tey could not turn it off, so the spammer sent messages for days and eventually my SG account got suspended.
IP Rules are super helpful in this case, still need to rotate when exposed but can limit the exposure.
The CEO was not pleased with the 30K (or maybe it was 60K) bill... and I just pointed at the CTO and was like "I fought this battle and was overruled"
It seems convenient until the credentials change (which they ought to now and then). Then when you check out an old revision of the project, it is broken. You end up having to copy and paste the new creds back in time and it's finicky as hell.
in the last startup I worked, all jwt tokens were created from a 10 letter long shared "secret" stored in json config files all over the place :p
even dev environments had same key lol
If they're dev-keys, I think this is pretty common.
Since it's of interest to HN, I am working on educating our very small team on how keys should be protected and used. I am the youngest developer by about 15 years. It's a very rural company and it often feels like all learning and passion for development stalled around 2005. It's a company that gave me a chance to grow into a development role with no previous experience so I feel indebted to try my best to keep the lights on.
I don't judge too harshly- anyone who has black and white principles on these matters has never worked in any other industry most likely... all you can do is your best to steer the ship and convey the downsides.
I think it's important too because it helps us understand how much friction people will tolerate.
In many cases, even a small amount of friction will cause people to stop functioning completely; I recently tried setting up vault and it was a nightmare, I understand why people avoid picking it up.
That doesn't mean we should not try; we have to become the advocates, arbiters and helpers for those systems.
Good luck, you're not alone.
It should be no surprise that people do insecure stuff under deadline pressure.
This is definitely true, but not actually surprising. It's much easier to notice that, say, a violin performance or plumbing repair is done very badly, than it is to actually do it correctly yourself.
Which also leads to a great deal of exasperation when people (either apparently or actually) don't even notice that what they're doing is insecure. There's a big difference between "yeah, it's broken, but it'd be a huge pain to fix and we'd probably get it wrong anyway, so we'd rather take our chances" versus "there is no problem".