[deleted]
How to mitigate risk from secrets leaks
31–40 of 60 posts
Re: How to mitigate risk from secrets leaks
#32You 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 )
I don't think those are mutually exclusive options :) Most developers, especially with lots of legacy apps are better off using a secrets manager. But there is no reason to not push the boundaries of security for new software and onboard passwordless and secretless options.
P.S.
I tried Infisical a couple of months ago. I think if I was Hashicorp Vault team's PM, I'd be worried. Your team has done such a great job at U.X. I was astonished to see an early startup with such a great integration catalog. I think you aced it - modern developers are desperate for out of the box integrations with 100+ services they have to use every day.
Re: How to mitigate risk from secrets leaks
#33Re: How to mitigate risk from secrets leaks
#34Even 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.
We use two factor leaks.
Put an encryption key in the code and use it to decrypt the environment on use to recover the API key. You have to get both leaks to recover the key.
Re: How to mitigate risk from secrets leaks
#35Earlier quoted context omitted.
Honest question, in terms of grammar, is JWT token similar to ATM machine? I always feel weird just saying “JWT” and almost always add the “token” part to the end for clarity, is that common?
I try hard to just say "the JWT". But I also try to only say "ATM"
I go the other direction and like to say JWT Web Token.
Re: How to mitigate risk from secrets leaks
#36Earlier quoted context omitted.
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 )
I don't think those are mutually exclusive options :) Most developers, especially with lots of legacy apps are better off using a secrets manager. But there is no reason to not push the boundaries of security for new software and onboard passwordless and secretless options. P.S. I tried Infisical a couple of months ago. I think if I was Hashicorp Vault team's PM, I'd be worried. Your team has done such a great job at…
Wow! Thanks you Alex. This feedback means a lot coming from you!
We're huge fans of Teleport, and learned a lot from you as a fellow YC company :)
Re: How to mitigate risk from secrets leaks
#37and that's why you use secret managers like infisical
Infrequent posting low karma users showing up on a random thread after nearly a year of inactivity to call out a relatively niche player which gets immediately replied to by the founder looks suspicious, I have to say. (EDIT: The founder has since deleted their comment, it had been quite downvoted before I replied)
Re: How to mitigate risk from secrets leaks
#38Even 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.
We use two factor leaks. Put an encryption key in the code and use it to decrypt the environment on use to recover the API key. You have to get both leaks to recover the key.
You have to combine that with some kind of assurances that the window that an key leak happens over is pretty finite, otherwise you can leak one key and not notice and you've lost your redundancy and you're no better off. And you may make incident response mistakes due to a false sense of security when you're made aware that the second key leak has happened.
So, you really need to be doing everything else correctly first and can't use that to fix sloppy key management and monitoring/prevention.
Re: How to mitigate risk from secrets leaks
#39Earlier quoted context omitted.
I don't think those are mutually exclusive options :) Most developers, especially with lots of legacy apps are better off using a secrets manager. But there is no reason to not push the boundaries of security for new software and onboard passwordless and secretless options. P.S. I tried Infisical a couple of months ago. I think if I was Hashicorp Vault team's PM, I'd be worried. Your team has done such a great job at…
Wow! Thanks you Alex. This feedback means a lot coming from you! We're huge fans of Teleport, and learned a lot from you as a fellow YC company :)
No problem! Keep it up with out of the box integrations, focus on U.X. and developer experience and I think you will be on track to become as big or bigger than Hashicorp :)
Re: How to mitigate risk from secrets leaks
#40Earlier quoted context omitted.
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 us…
Interesting. You already don’t have to worry about revoking JWTs if they’re sufficiently short lived. This gives you the exact level of protection as a short-lived mTLS cert, because if that gets stolen the attacker can continue to establish connections until it expires, unless as you say you revoke the certificate. So clearly I am missing something.