[HN Gopher] 1 in 10 developers leaked an API-key in 2022
___________________________________________________________________
1 in 10 developers leaked an API-key in 2022
Author : vmatsiiako
Score : 24 points
Date : 2023-05-27 21:13 UTC (1 hours ago)
(HTM) web link (www.reversinglabs.com)
(TXT) w3m dump (www.reversinglabs.com)
| bigmattystyles wrote:
| It'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.
| revskill wrote:
| 100% developers leaked JWT token .
| lioeters wrote:
| Aren't JWT tokens supposed to be public?
| treve wrote:
| 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.
| hoofedear wrote:
| 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?
| lioeters wrote:
| > 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
| djbusby wrote:
| I try hard to just say "the JWT". But I also try to only
| say "ATM"
| adhesive_wombat wrote:
| Bonus points if you pronounce it like a Greek "o" (joat)
| or a Welsh "w" (joot)!
| yarg wrote:
| That's omega?
| replygirl wrote:
| you're telling me the w doesn't stand for rapture?
| ben_w wrote:
| "Personal PIN Identification Number" is my favourite
| example.
| DrFell wrote:
| API keys are also not secrets, they're just like an ID for
| your account. You just restrict the kind of request they
| respond to, and how they will respond, based on the key.
| https://www.youtube.com/watch?v=2_HZObVbe-g&t=51s
| taeric wrote:
| 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?
| alexk wrote:
| 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.
| danappelxx wrote:
| How does this approach practically differ from using short-
| lived JWTs+TLS?
| Macha wrote:
| This seems implausibly high. Is it including stuff like putting
| password=replaceme in an example config file?
| moffkalast wrote:
| Well 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. No
| surprise that they get leaked all the time now, though at least
| one can cancel them at any time... and then have to spend an
| hour or two replacing it everywhere.
| londons_explore wrote:
| 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.
| cowsup wrote:
| 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.
| p1necone wrote:
| 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.
| suddenclarity wrote:
| 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.
| hanyiwang wrote:
| and that's why you use secret managers like infisical
| vmatsiiako wrote:
| thanks for mentioning Infisical (I'm one of the founders)! We
| indeed help devs prevent leaking secrets to git and manage them
| across the whole infra. Check it out at https://infisical.com
| ed25519FUUU wrote:
| Even 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.
|
| Still say east to do what's wrong.
___________________________________________________________________
(page generated 2023-05-27 23:00 UTC)