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

Google API keys weren't secrets, but then Gemini changed the rules

trufflesecurity.com

Post reply on HN
Print view View original

121–130 of 326 posts

Re: Google API keys weren't secrets, but then Gemini changed the rules

#121

Post by joking »

chinathrow wrote: post #111
voidUpdate wrote: post #109

> This makes sense. These keys were designed as project identifiers for billing, and can be further restricted with (bypassable) controls like HTTP referer allow-listing. They were not designed as authentication credentials. Can't you just run up a huge bill for a developer by spamming requests with their key? I don't see how this wasn't always an issue?

I guess this was an issue all along - but the cost per request is most def way higher for LLM API calls than for e.g. a Maps API call.

with llms maybe you can reuse their api for your own benefit instead of just showing some maps, so the issue is even worse that only cost.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#122

Post by ddalex »

crest wrote: post #63
827a wrote: post #15

Earlier quoted context omitted.

Yeah its tremendously unclear how they can even recover from this. I think the most selective would be: they have to at minimum remove the Generative Language API grant from every API key that was created before it was released. But even that isn't a full fix, because there's definitely keys that were created after that API was released which accidentally got it. They might have to just blanket remove the Generative…

I hope Google has a database with the creation timestamp for every API key they issued.

I think Google has a database with everything. EVERYTHING.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#123

Post by breakingcups »

lpribis wrote: post #110
vincnetas wrote: post #92

This totally reminds me of SSN use, when initially they were just a number (not secret) to identify a person, and then suddenly people started to use them as a key for authorisation, because someone had a bright idea how to implement things fast/simple/cheap (cheap part comes at expense of others)

Rather than being about fast/simple/cheap, I think using SSN as a key was more about the fact that SSN is the only common identifier that almost all US citizens have.

Yes, designing and implementing a new common identifier almost all US citizens have would have been less cheap and fast.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#125

Post by sandrello »

Since I've never used them, how could API keys for Firebase or Maps be safe for embedding in client side code?

I mean, I get that authentication to the service is performed via other means, but what's the use of the key then?

I'm guessing it's just a matter of binding service invocations to the GCP Project to be billed, by first making sure that the authenticated principal has rights on that project, in order to protect from exfiltration. That would still be a strange use case for what gets called an "API key".

Re: Google API keys weren't secrets, but then Gemini changed the rules

#126

Post by Dylan16807 »

decimalenough wrote: post #46
warmedcookie wrote: post #4

What's frustrating is that a lot of these keys were generated a long time ago with a small amount of GCP services that they could connect to. (Ex. Firebase remote config, firestore, etc.) When Gemini came around, rather than that service being disabled by default for those keys, Gemini was enabled, allowing exploiters to easily utilize these keys (Ex. a "public" key stored in an APK file)

Gemini API is not enabled by default, a project owner has to go explicitly enable it. The problem described here is that developer X creates an API key intended for Maps or something, developer Y turns on Gemini, and now X's key can access Gemini without either X or Y realizing that this is the case. The solution is to not reuse GCP projects for multiple purposes, especially in prod.

It's not enabled by default on projects but it's enabled by default on keys.

It shouldn't be enabled by default on either one.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#127

Post by Dylan16807 »

lpribis wrote: post #110
vincnetas wrote: post #92

This totally reminds me of SSN use, when initially they were just a number (not secret) to identify a person, and then suddenly people started to use them as a key for authorisation, because someone had a bright idea how to implement things fast/simple/cheap (cheap part comes at expense of others)

Rather than being about fast/simple/cheap, I think using SSN as a key was more about the fact that SSN is the only common identifier that almost all US citizens have.

I think you're using the word "key" differently than OP. You're talking about identifiers, and they're talking about security.

SSNs were a good potential identifier, until the people that needed security cheaped out and started using SSNs as a bad implementation of security. Now they're bad at both purposes!

Re: Google API keys weren't secrets, but then Gemini changed the rules

#129

Post by Dylan16807 »

saagarjha wrote: post #62
masklinn wrote: post #50

Earlier quoted context omitted.

Of course, how could a writer writing have writing chops and use writing techniques? It boggles the mind that anyone thinks that would ever happens. Must have been aliens.

A good writer knows when to use literary techniques.

They work just fine in this post.

Re: Google API keys weren't secrets, but then Gemini changed the rules

#130

Post by Dylan16807 »

SecretDreams wrote: post #7
bryanrasmussen wrote: post #5

Earlier quoted context omitted.

How do you know that this blog post was written by ChatGPT?

It's too structured and consistent. Imo. Has that AI smell to it, but I guess humans will eventually also start writing more like the AIs they learn from.

This is the first time I've seen people accuse AI text of being "too structured and consistent" compared to human text. Usually it's about specific patterns or tons of repetition or outright mistakes.
Post reply on HN