Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to mitigate risk from secrets leaks

reversinglabs.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: How to mitigate risk from secrets leaks

#41

Post by lamontcg »

p1necone wrote: post #23
cowsup wrote: post #14

Earlier 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.

Yeah, for $curious_reasons we shipped our unit tests with our binaries and fake credentials would set off enterprise security scanners (although in our case it was a real enough looking PKI cert and not just data with username/password fields in it).

Re: How to mitigate risk from secrets leaks

#43

Post by danenania »

zifeo wrote: post #27
hanyiwang wrote: post #9

and 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!

EnvKey[1] is another option (I’m the founder).

We have similarly simple UX but are more robust on security. Browser-based end-to-end encryption as offered by Infisical is a bit of a fig leaf—it doesn’t protect against insider threats.

1 - https://envkey.com

Re: How to mitigate risk from secrets leaks

#44

Post by alexk »

danappelxx wrote: post #40
alexk wrote: post #28

Earlier quoted context omitted.

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.

They key difference is with mTLS approach you'd have to steal the private key of the client certificate if you want to impersonate the client. In most secure deployments of mTLS and short lived certs, private key never escapes the TPM, Secure enclave or Yubikey, so it's extremely hard to mount an attack and impersonate a service.

With JWT (assuming it's not bound) you can steal JWT token and re-use it until it expires.

Re: How to mitigate risk from secrets leaks

#45

Post by adhesive_wombat »

replygirl wrote: post #42
adhesive_wombat wrote: post #33

Earlier quoted context omitted.

Depends. Is your name Wodger or Bwian? Do you have friends in Wome?

it’s a joke about the new testament.

So is this, indirectly: https://youtu.be/7Lc86JUAwwg. Though sadly it didn't include the Book of Wevelations.

Re: How to mitigate risk from secrets leaks

#46

Post by replygirl »

adhesive_wombat wrote: post #45
replygirl wrote: post #42

Earlier quoted context omitted.

it’s a joke about the new testament.

So is this, indirectly: https://youtu.be/7Lc86JUAwwg . Though sadly it didn't include the Book of Wevelations.

no, just a play on omega, but thanks for the nostalgia and the laugh :)

Re: How to mitigate risk from secrets leaks

#47

Post by danappelxx »

alexk wrote: post #44
danappelxx wrote: post #40

Earlier quoted context omitted.

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.

They key difference is with mTLS approach you'd have to steal the private key of the client certificate if you want to impersonate the client. In most secure deployments of mTLS and short lived certs, private key never escapes the TPM, Secure enclave or Yubikey, so it's extremely hard to mount an attack and impersonate a service. With JWT (assuming it's not bound) you can steal JWT token and re-use it until it expire…

Right! Which is why we use (public) short-lived JWTs and (private) long-lived refresh tokens. What’s missing?

Re: How to mitigate risk from secrets leaks

#48

Post by danenania »

lamontcg wrote: post #38
akira2501 wrote: post #34

Earlier quoted context omitted.

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 f…

I’m the founder so naturally a bit biased, but with EnvKey[1] you can get pretty strong assurances by using IP restrictions. Even if an attacker gets hold of an ENVKEY token (used to fetch and decrypt an app’s secrets), if you lock it down to the IP range of your severs, they’ll only be able to use it if they can get inside your servers (at which point you are fully compromised regardless). Just getting the key by itself isn’t enough.

I think this is about as good as you can do, honestly, since even using something along the lines of short-lived certs, you still have secrets to protect, and you lose the ability to easily do immediate revocations.

1 - https://envkey.com

Re: How to mitigate risk from secrets leaks

#49

Post by rcme »

alexk wrote: post #15

You 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 do you generate the short-lived certs?

Re: How to mitigate risk from secrets leaks

#50

Post by still_grokking »

alexk wrote: post #44
danappelxx wrote: post #40

Earlier quoted context omitted.

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.

They key difference is with mTLS approach you'd have to steal the private key of the client certificate if you want to impersonate the client. In most secure deployments of mTLS and short lived certs, private key never escapes the TPM, Secure enclave or Yubikey, so it's extremely hard to mount an attack and impersonate a service. With JWT (assuming it's not bound) you can steal JWT token and re-use it until it expire…

I still don't get the difference.

If someone steals your secrets you're screwed. No matter what kind of secrets that are. That's clear.

But if you keep your secrets in a HSM (TPM, SmartCard, …) and only use them to derive session keys directly on the secure device there is absolutely no difference which concrete tech you're using (given that secure cryptography is in place).

mTLS is a great approach, no question. But I just don't see how it's more secure than any other public key crypto.

Post reply on HN