Apparently there was a "blogpost" of a developer showing of their code, where they accidentally leaked access tokens in a piece of commented code: https://archive.ph/mP3bh
This is completely unverified though, so take it with a grain of salt.
This is completely unverified though, so take it with a grain of salt.
[1] https://regex101.com/r/CLg9TK/1
[2] https://github.com/zricethezav/gitleaks/blob/master/config/g...
Is it covered by a different rule perhaps?
> 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.
Use vault, env vars, GitHub/GitLab secrets, anything but string literals!!!
It’s end-to-end encrypted, cloud or self-hosted, and very quick to integrate.
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)
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)
Static, long lived secrets with limited governance that have no conditional access guards are weapons of mass self destruction.
Refreshing an environment variable that has changed is (for me) a line I won't cross. Time to write the app a different way, once that becomes a concern.
Do you know a way where RBAC can be used for the above?
For us, we're using long lived credentials in this space using IAM Users but with very tightly controlled authorisations.
https://aws.amazon.com/about-aws/whats-new/2022/07/aws-ident...
The oidc subject includes the GitHub org, repo, branch, and environment for the IAM assume role policy to match or filter.
You add the long lived IAM user API key/secret to it and it stores it in a password protected storage (MacOS keychain or similar).
Then you invoke aws-vault with an IAM role and command, and it will handle obtaining short-lived credentials scoped to that role (including TOTP 2-factor code auth), and then run the command with those temporary credentials as env vars.
With the right AWS permissions on your user, it can also automatically rotate the IAM user API keys for you.
Not Invented Here
I still use aws-vault, though, when I'm not in a position to set up AWS SSO.
aws-vault is one of them, though out of support now, aws-okta [1] is another.
Just an FYI it's no longer supported and it looks like the fork has gone stagnant, too.
For example, for AWS you can create long lived credentials for users which are scoped to only allow one operation, namely obtaining a short lived token (with the aid of a hardware token such as a Yubikey) with scope to perform other operations.
AWS guide here: https://aws.amazon.com/blogs/security/enhance-programmatic-a...
> it's senselessly adding fuel to our political division.
This comment, whether you realize it or not, is coming from a place of extreme social privilege.
Remember that for the majority of people, politics is not a game. It is serious. People lose their rights to live the life they want all the time. Sometimes those politics turn violent and people lose everything.
Something got shanghaied isn't a pejorative in the way that Trump acolytes use "China virus".
Are you unaware of the Chinese Exclusion Act of 1882 -- which is exactly around the time that this term was popular and in common use?
At work we codename security issues we are working on for Slack channels, etc. We use unrelated names that you could get from a name generator.
According to this tweet [0] they have a "threat intelligence" department that continually monitors for potential issues. It makes sense that they would be on the lookout for leaks of this nature, as they are highly dependent on correctly verifying and identifying their customers.
[0] https://twitter.com/cz_binance/status/1543700689611792386
I can't count the amount of SO questions I've had to edit from others posting live API Keys for everything from custom services to AWS.
But as mentioned below - Still advised to change your keys for obvious reasons
The only thing you can do is rotating the token/secret.
Something like giving false confidence to the user. Not the best idea.
Of course, then your secret key checker would need to build that string by concatenating so that it wouldn't set off itself.
A project I maintain, Gitleaks, can easily detect "unique" secrets and does a pretty good job at detecting "generic" secrets too. In this case, the generic gitleaks rule would have caught the secrets [1]. You can see the full rule definition here [2] and how the rule is constructed here [3].
[1] https://regex101.com/r/CLg9TK/1
[2] https://github.com/zricethezav/gitleaks/blob/master/config/g...
[3] https://github.com/zricethezav/gitleaks/blob/master/cmd/gene...
Here is a full explanation if you are interested: https://blog.gitguardian.com/why-detecting-generic-credentia...
https://res.cloudinary.com/da8kiytlc/image/upload/v164614852...