Live data from Hacker News

How to mitigate risk from secrets leaks

reversinglabs.com

11–20 of 60 posts

Re: How to mitigate risk from secrets leaks

#11
post #3
post #2

100% developers leaked JWT token .

Aren't JWT tokens supposed to be public?

No? They are literally your authentication. They are time limited, but still pretty private.

Done well, they have an audience set for what they authenticate. Which can limit the exposure back to the issuer. But you are supposed to trust that holding the token means you know who the user is.

Right?

Re: How to mitigate risk from secrets leaks

#12
post #3
post #2

100% developers leaked JWT token .

Aren't JWT tokens supposed to be public?

Depends on the context. JWTs are very often used as a type of session token. So if your token is public, it might allow someone to act on your behalf for whatever service you're using.

So while users are allowed to read the token and its contents, you don't want user-identifying tokens to fall in the hands of someone else.

You might be thinking of a public key.

Re: How to mitigate risk from secrets leaks

#14

Does 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 credentials to specific individuals.

Re: How to mitigate risk from secrets leaks

#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 than we wanted, because it's not trivial to replace API keys, but we see more and more companies using mTLS + short lived certs as alternative to shared secrets.

Re: How to mitigate risk from secrets leaks

#19
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 does this approach practically differ from using short-lived JWTs+TLS?
Post reply on HN