Hacker News new | ask | show | jobs
by zricethezav 1447 days ago
Assuming this unverified version of the story is true, the danger of accidentally leaking credentials in code is enormous and one of the reasons I continue to maintain and develop gitleaks. Those credentials[1] would have been caught by the gitleaks' generic rule [2]

[1] https://regex101.com/r/CLg9TK/1

[2] https://github.com/zricethezav/gitleaks/blob/master/config/g...

3 comments

Fantastic tool. We all know that _we_ wouldn't leak keys, but we have all been the person to 'rm -rf /' or 'delete * from prod where 1=1;', so it's just a matter of time.

Is there a plugin that streamers could use to blur suspected keys on stream? Would that be something interesting to work on do you think? (I'm not a streamer but it sounds fun)

When I was looking into the streaming side of things I set up an overlay image which could be toggled with a hotkey to hide my screen (it actually also hid my desktop scene too in case the image didn't load or whatever)

My main precaution though was separating dev/prod and never looking at prod stuff online. Worst case someone could spin up some guff in my dev/test account until I can cycle the credentials

In my case the separation also included a different system user on my computer for stream work. Possibly overkill but why risk it when the costs are so low?

I can't see myself trusting a key blurring app if I'm honest. Rather fix the issue earlier in the process than rely on something that would probably break on edge cases (word wrap enabled? Here's the key but it's in two parts, that sort of thing)

I agree I'd probably not trust it either, I'd be tempted to buy a completely seperate machine just out of paranoia
I think it would be a good tool to have, I had to contact a conference organizer once who switched tabs while sharing her screen in a recording and revealed a note in Google Keep that read "LastPass master password" xD
It doesn't help that so many tools are like "give me your secret key in plain text in the config file" without at least offering a link to a webpage on the github of how you could secure your keys and use this software
hardcoded creds in example documentation... T_T

Use vault, env vars, GitHub/GitLab secrets, anything but string literals!!!

Vault is not just a drop in and go system - setting up a vault instance is an ordeal in and of itself, and the pricing for vault on hashicorp cloud is incredibly expensive. The problem with the other options is that you have to get the secrets into environment variables, or out of github/lab secrets and into your application. To use most of the services like AWS secrets manager, vault, etc, it will cost you more to manage secrets than it will to host the app on a small DO droplet for example.
Self-hosted Vault within a minimum Kubernetes cluster in GCP costs us roughly $35 a month. Maintenance effort can be neglected if not scaling. Vault has its learning curve there but I think it's totally worth it, given its secret management and API-first features integrated with many other DevOps tools.
$35/month is more than a small team will pay on source control.
If anyone’s looking for something more secure than vanilla env vars but simpler than Vault, you could check out EnvKey[1]. Disclaimer: I’m the founder.

It’s end-to-end encrypted, cloud or self-hosted, and very quick to integrate.

1 - https://envkey.com

It feels like just only yesterday secrets in env vars were considered faux pas :)
How were the words selected for the regex? It's interesting that "pass" is not there and breaks detection in your first link, but I assume they were chosen based on the statistics?

Is it covered by a different rule perhaps?

`pass` by itself might introduce false positives. `passwd` and `password` are common and more likely to be in the ROI of a secret. That said, I'm not opposed to `pass` by itself. I'll have to think about this one...

> but I assume they were chosen based on the statistics?

Nope, not statistics. Identifiers and keywords are chosen based on what I see out in the wild being a software engineer.