8 ms·
How to mitigate risk from secrets leaks
- deleted 3y ago[deleted]
- revskill 3y ago100% developers leaked JWT token .
- lioeters 3y agoAren't JWT tokens supposed to be public?
- hoofedear 3y agoHonest 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?
- lioeters 3y ago> RAS syndrome (where "RAS" stands for "redundant acronym syndrome", making the phrase "RAS syndrome" homological) is the redundant use of one or more of the words that make up an acronym (or other initialism) in conjunction with the abbreviated form. > Many style guides advise against usage of these redundant acronyms in formal contexts, but they are widely used in colloquial speech. https://en.wikipedia.org/wiki/RAS_syndrome https://en.wikipedia.org/wiki/RAS_syndrome
- djbusby 3y agoI try hard to just say "the JWT". But I also try to only say "ATM"
- adhesive_wombat 3y agoBonus points if you pronounce it like a Greek "ω" (joat) or a Welsh "w" (joot)!
- yarg 3y agoThat's omega?
- replygirl 3y agoyou're telling me the w doesn't stand for rapture?
- adhesive_wombat 3y agoDepends. Is your name Wodger or Bwian? Do you have friends in Wome?
- replygirl 3y agoit’s a joke about the new testament.
- adhesive_wombat 3y agoSo is this, indirectly: https://youtu.be/7Lc86JUAwwg https://youtu.be/7Lc86JUAwwg. Though sadly it didn't include the Book of Wevelations.
- replygirl 3y agono, just a play on omega, but thanks for the nostalgia and the laugh :)
- onionisafruit 3y agoI go the other direction and like to say JWT Web Token.
- ben_w 3y ago"Personal PIN Identification Number" is my favourite example.
- taeric 3y agoNo? 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?
- treve 3y agoDepends 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.
- deleted 3y ago[deleted]
- jamietanna 3y agoRelated discussion https://news.ycombinator.com/item?id=24352360 https://news.ycombinator.com/item?id=24352360
- londons_explore 3y agoDoes 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.
- cowsup 3y agoNo. 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.
- p1necone 3y agoMethodology 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.
- cowsup 3y agoGood 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...
- lamontcg 3y agoYeah, 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).
- simonw 3y agoIt looks like the best description of the methodology is here: https://docs.gitguardian.com/secrets-detection/detectors/generics/generic_high_entropy_secret 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.
- hanyiwang 3y agoand that's why you use secret managers like infisical
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- zifeo 3y agoWe migrated a few month ago from doppler to infisical as the latter supports end-to-end encryption and happy so far!
- danenania 3y agoEnvKey[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 https://envkey.com
- dangtony98 3y agoI 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?
- danenania 3y agoWell, 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.
- bigmattystyles 3y agoIt’s way higher than that if you mean just leaving it in an MR or even checking it in. Or even a relatively open internal file system. It’s not if, it’s about the plan when you do.
- alexk 3y agoYou 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/ https://goteleport.com/docs/machine-id/introduction/ Another great option is SPIFFEE https://spiffe.io/ 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.
- danappelxx 3y agoHow does this approach practically differ from using short-lived JWTs+TLS?
- alexk 3y agoShort 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 https://latacora.micro.blog/2018/06/12/a-childs-garden.html [2] https://connect2id.com/learn/token-binding https://connect2id.com/learn/token-binding
- danappelxx 3y agoInteresting. 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.
- Macha 3y agoThis seems implausibly high. Is it including stuff like putting password=replaceme in an example config file?
- moffkalast 3y agoWell 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.
- segudev 3y agoIf 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-leaks-public-github https://www.gitguardian.com/complimentary-audit-secrets-leak... More details on how it works: https://blog.gitguardian.com/github-secrets-leak-free-audit/ https://blog.gitguardian.com/github-secrets-leak-free-audit/
- suddenclarity 3y agoI 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.
- dangtony98 3y agoDefinitely 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.
- ed25519FUUU 3y agoEven 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.
- akira2501 3y agoWe 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.
- lamontcg 3y agoYou 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.
- danenania 3y agoI’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 https://envkey.com