I skimmed the report pdf and saw no mention of validating the data. So I assume pushing an example env file would be flagged as a leak? I understand that it's tricky to validate and even more so when having millions of data points but the method seems shaky. It's like all those automatic error analysers that repo authors tend to hate due to all false positives.
How to mitigate risk from secrets leaks
21–30 of 60 posts
Re: How to mitigate risk from secrets leaks
#22Re: How to mitigate risk from secrets leaks
#23Does this include deliberately sharing an API key, but in a 'not best practices' way? ie. "Here, just run document.cookie='SID=EB73542386AF235' " Then you'll be logged in as an account that can do what you're trying to do.
No. This checks public GitHub commits that contain secret credentials; in 2022, over 33% were specific to known APIs, such as AWS access keys or MongoDB credentials, while the remaining 67% were deemed "generic." According to the report, generic ones include secrets such as "a company email and a password that would end up hard-coded in a file." It's not scanning developer support tickets to see when devs hand over c…
Methodology is super important here though. I've used static analysis tools that identify every single bit of fake unit test data with a field called 'username', 'email' etc as leaked credentials.
Re: How to mitigate risk from secrets leaks
#24This seems implausibly high. Is it including stuff like putting password=replaceme in an example config file?
Well ever since github switched from password auth to token only, it's been impractical to do anything but copy paste it from somewhere and have it cache/store instead of typing it in from memory every time like one could do with passwords. Probably one of the worse security decisions I've ever seen, reducing github security to the same kind of level that those corpo directives do that need password switching every month, so it's just kept on a post-it on the machine lol.
No surprise that they get leaked all the time now, though at least one can cancel them at any point... and then you have to spend an hour or two replacing the cached version everywhere.
Re: How to mitigate risk from secrets leaks
#25Even if you try and use best practices, the whole ship is just LEAKY!
For example you store your secrets in the env. Well your program crashes and the log capture software dumps the entire env, or it’s included in some crash report.
Leaks from every corner.
Re: How to mitigate risk from secrets leaks
#26and that's why you use secret managers like infisical
[deleted]
Re: How to mitigate risk from secrets leaks
#27and that's why you use secret managers like infisical
We migrated a few month ago from doppler to infisical as the latter supports end-to-end encryption and happy so far!
Re: How to mitigate risk from secrets leaks
#28You can't leak API keys if there are no API keys to leak! The article recommends OIDC for apps, which is a step up, especially if you rotate the bearer token, however there is another option - use short-lived certs. Our project Machine ID is replacing API keys with short-lived certificates: https://goteleport.com/docs/machine-id/introduction/ Another great option is SPIFFEE https://spiffe.io/ The adoption is slower t…
How does this approach practically differ from using short-lived JWTs+TLS?
Short version is that with mTLS and short-lived certificates you don't have to worry about anyone stealing and re-using your JWT tokens and revoking tokens.
LVH from Latacora explains it way better than I could in "A child's garden of inter-service authentication" [1]
However, here is my view:
If your token is not bound to the connection, someone can steal and reuse it, just like any other token. It is possible to use OAuth token binding [2], but at this level of complexity, mTLS + short lived certs deliver the same security and are easier to deploy.
It's easy to mess up JWT signatures, although, to be fair, it's not like X.509 certificates format is any better, however it's been more tested over years of use.
[1] https://latacora.micro.blog/2018/06/12/a-childs-garden.html [2] https://connect2id.com/learn/token-binding
Re: How to mitigate risk from secrets leaks
#29You can't leak API keys if there are no API keys to leak! The article recommends OIDC for apps, which is a step up, especially if you rotate the bearer token, however there is another option - use short-lived certs. Our project Machine ID is replacing API keys with short-lived certificates: https://goteleport.com/docs/machine-id/introduction/ Another great option is SPIFFEE https://spiffe.io/ The adoption is slower t…
Frankly, I think it will take years to replace API-keys (if it will ever happen). Developers are much better-off using CLI tools that prevent leaking secrets by blocking commits to git (e.g., https://github.com/Infisical/infisical or https://github.com/trufflesecurity/trufflehog)
Re: How to mitigate risk from secrets leaks
#30Earlier quoted context omitted.
No. This checks public GitHub commits that contain secret credentials; in 2022, over 33% were specific to known APIs, such as AWS access keys or MongoDB credentials, while the remaining 67% were deemed "generic." According to the report, generic ones include secrets such as "a company email and a password that would end up hard-coded in a file." It's not scanning developer support tickets to see when devs hand over c…
Methodology is super important here though. I've used static analysis tools that identify every single bit of fake unit test data with a field called 'username', 'email' etc as leaked credentials.
Good point. I wish they included more details about how they performed their searches, but I understand not wanting to feed tips and tricks to the bad guys...