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

51–60 of 60 posts

Re: How to mitigate risk from secrets leaks

#51

Post by xyzzy123 »

still_grokking wrote: post #50
alexk wrote: post #44

Earlier quoted context omitted.

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…

mTLS tends to add infrastructure complexity, I much prefer it when you can "terminate" auth where you like in the ingress path for user-facing stuff rather than first-hop auth.

I wish there were "real" standards and a better ecosystem for request signing.

Re: How to mitigate risk from secrets leaks

#52

Post by dangtony98 »

danenania wrote: post #43
zifeo wrote: post #27

Earlier quoted context omitted.

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

I wouldn't undermine and characterize it as fig leaf personally. I think this would raise a natural question on my end which is how do you evaluate the security of platforms like 1Password, Bitwarden, Vault, all of which also offer browser-based alternatives?

Re: How to mitigate risk from secrets leaks

#53

Post by dangtony98 »

suddenclarity wrote: post #21

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.

Definitely tricky to validate. Most tools out there offer multiple methods of excluding certain data-points whether it be by adding a comment by it to indicate intentionality, a file containing specs to exclude like values or matching patterns, or a UI that you can use "post-leak" to dismiss it as false positive.

I definitely resonate with your point though on the automatic errors due to false positives. There is a lot of room for improvement.

Re: How to mitigate risk from secrets leaks

#55

Post by danenania »

dangtony98 wrote: post #52
danenania wrote: post #43

Earlier quoted context omitted.

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

I wouldn't undermine and characterize it as fig leaf personally. I think this would raise a natural question on my end which is how do you evaluate the security of platforms like 1Password, Bitwarden, Vault, all of which also offer browser-based alternatives?

Well, what’s the point of end-to-end encryption? It’s so that even if the service gets hacked or has an employee go rogue, sensitive data will still be safe, right?

That’s what the average person thinks they are getting when they sign up for a service that advertises end-to-end encryption, but when it’s browser-based, that simply isn’t true. If a browser-based service gets hacked, it’s trivial for an attacker to disable the encryption, steal private keys, or just steal secrets directly, and it can be done in a way that leaves no record and is very difficult for the end-user to detect.

So you have a security measure that is implemented in a way that fully subverts the stated purpose of said security measure. I think fig leaf is a fair characterization.

You’re right that Infisical is far from the only product doing it. Though it’s fairly common knowledge in the security and encryption community, most developers and most users of these products aren’t aware of this issue, so for now, there isn’t a lot of incentive to do it right.

Re: How to mitigate risk from secrets leaks

#56

Post by dangtony98 »

danenania wrote: post #55
dangtony98 wrote: post #52

Earlier quoted context omitted.

I wouldn't undermine and characterize it as fig leaf personally. I think this would raise a natural question on my end which is how do you evaluate the security of platforms like 1Password, Bitwarden, Vault, all of which also offer browser-based alternatives?

Well, what’s the point of end-to-end encryption? It’s so that even if the service gets hacked or has an employee go rogue, sensitive data will still be safe, right? That’s what the average person thinks they are getting when they sign up for a service that advertises end-to-end encryption, but when it’s browser-based, that simply isn’t true. If a browser-based service gets hacked, it’s trivial for an attacker to disa…

First off, I want to point out that browser-based services and applications can be made secure; we should keep this one clear, especially for readers here, because otherwise it would invalidate most if not all services that exist accessible via browser. Take AWS which houses infrastructure for so many organizations; we access it via browser and this is totally fine.

The assumption you highlight is specifically "if a browser-based service gets hacked." Well yes, if any browser-based service, like AWS, got hacked then it'd be all game over. However, given that appropriate security measures are implemented/taken, we can in fact design web applications that are securely accessible via browser; this is the basis for how we access applications on the web securely, those that are not end-to-end encrypted (E2EE).

What I'm trying to say is that your assumption is based on a particular case that is "if a browser-based service gets hacked." I think, however, if this assumption occurred to many other non-E2EE services we use on a daily basis, we'd have a huge problem as well. Now, the reverse assumption that is the browser-based service is not hacked, coupled with an E2EE architecture, I believe it's possible to design a secure system here where even the server cannot read the values of secrets which is a point of E2EE.

Re: How to mitigate risk from secrets leaks

#57

Post by danenania »

dangtony98 wrote: post #56
danenania wrote: post #55

Earlier quoted context omitted.

Well, what’s the point of end-to-end encryption? It’s so that even if the service gets hacked or has an employee go rogue, sensitive data will still be safe, right? That’s what the average person thinks they are getting when they sign up for a service that advertises end-to-end encryption, but when it’s browser-based, that simply isn’t true. If a browser-based service gets hacked, it’s trivial for an attacker to disa…

First off, I want to point out that browser-based services and applications can be made secure; we should keep this one clear, especially for readers here, because otherwise it would invalidate most if not all services that exist accessible via browser. Take AWS which houses infrastructure for so many organizations; we access it via browser and this is totally fine. The assumption you highlight is specifically "if a…

Sure, my point wasn't that a browser-based product is automatically insecure, just that end-to-end encryption implemented in a browser has minimal security benefit. The whole point of E2EE is to avoid leaking data even if you do get hacked or have an employee go rogue despite your best efforts.

"even the server cannot read the values of secrets"

I have to disagree there. Your server can easily read the values of secrets--it just needs to include an extra snippet of JS in the response to a single request. You're asking users to trust that your server won't do this, but they have no practical way to verify it. That isn't the case for EnvKey, which is all I wanted to point out.

Please don't take it the wrong way--you have clearly built a product that has good UX and that people like and I congratulate you on that. Many users out there will probably prefer the tradeoffs you've made, while others will prefer EnvKey's. I think it's fair, in the spirt of friendly competition, to highlight where those differences are so that people can make up their own minds with an accurate understanding of the threat model of each approach.

Re: How to mitigate risk from secrets leaks

#58

Post by segudev »

Macha wrote: post #17

This seems implausibly high. Is it including stuff like putting password=replaceme in an example config file?

If the numbers look suspicious to you, I would suggest you check what is found more specifically about your company/organization.

GitGuardian can provide an automatic audit of your company-specific leaks we found on GitHub. Just ask: https://www.gitguardian.com/complimentary-audit-secrets-leak...

More details on how it works: https://blog.gitguardian.com/github-secrets-leak-free-audit/

Re: How to mitigate risk from secrets leaks

#59

Post by simonw »

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.

It looks like the best description of the methodology is here: https://docs.gitguardian.com/secrets-detection/detectors/gen...

It's pretty much checking if there's a variable called "_token" or "_secret" or similar which is then assigned to a string matching a regex looking for high entropy random-looking values.

Re: How to mitigate risk from secrets leaks

#60

Post by vladvasiliu »

still_grokking wrote: post #50
alexk wrote: post #44

Earlier quoted context omitted.

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…

If I'm not mistaken, the difference is that in the case of JWT, your app manipulates the secret directly, so it must show up in clear form somewhere, from the app's perspective.

So, if the app host is compromised, the attacker shouldn't have too hard a time to extract the JWT and use it from somewhere else.

In contrast, with an HSM, the attacker would need to have the HSM sign any new connection attempt, which should be a bit more involved if it happens on a different machine.

Post reply on HN