Live data from Hacker News

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

trufflesecurity.com

111–120 of 326 posts

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

#111

> 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.

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

#112

Earlier quoted context omitted.

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.

You are wrong that increasing projects have no cost; many services have project based costs (Cloud Armour rules cannot be used cross project at the base tier), many services (mostly observeability) degrade significantly cross project, the Google Cloud Console _sucks_ cross project. You are also wrong in saying there are no projects that could reasonably have a safe api key made unsafe by this exploit. One example, a…

You may have responded to one comment here. The comment you responded to is actually in agreement with you.

[Edit: It's likely that you intended to reply to this comment: https://news.ycombinator.com/item?id=47163147 ]

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

#113
post #71
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 started replying with a clever approach to layer scopes onto keys… but nope. Doesn’t work. How did this get past any kind of security review at all? It’s like using usernames as passwords.

Maliciously thinking allowing this increase billable. Thus it increases the bottom line and make stock go up... Which is good for vesting...

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

#116

This seems so… obvious? How can a company of this size, with its talent and expertise, not have standardized tests or specs preventing such a blatant flaw?

First of all, Google is a shell of the company it used to be. That said, I’d actually argue there’s an evolutionary explanation behind this where at a certain size, and more importantly complexity, an oversight like this becomes even more likely, not less.

Another takeaway: if Google can become a shell of what it once was (in terms of institutional competence, I assume you mean; Alphabet market cap seems to be doing just fine), so can your organization. As such: making something that isn't supposed to be part of your security strategy, look like it could be, is actually a long-term security risk. Sooner or later a new team will not read your own documentation, and jump to wrong conclusions. Also, it probably trains a bad security posture into your users. How many inexperienced devs saw that it was safe and expected (and apparently even required) to leave these keys out in the open, and concluded that the same logic might apply to someone else's API keys?

I think this was much less likely to happen without the needless obfuscation. If the only purpose is to identify what project the data is for, and you're trusting the client to report that value, and counseling the client to use that value in a way that trivially exposes it to everyone... what is the point of making it look like cryptic garbage? Just use the account signup name or something, and don't call it a "key" in your query parameters. Keys are supposed to unlock stuff. A name tag is not a key.

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

#118

This seems so… obvious? How can a company of this size, with its talent and expertise, not have standardized tests or specs preventing such a blatant flaw?

Security. The final frontier. Where no developer has ever bothered before.

To boldly allow to go where many have gone before (but shouldn't have been able to)...

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

#119

[flagged]

The new code changes from not existing, to existing.

Indeed, the key doesn't change. The new capability comes from the new code.

It would not be a re-evaluation of risk, because this is a new project. The evaluation of risk is supposed to come at the moment when the new capability is implemented, and consciously tied to an existing key type, which was previously advertised as non-secret.

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

#120

This seems so… obvious? How can a company of this size, with its talent and expertise, not have standardized tests or specs preventing such a blatant flaw?

First of all, Google is a shell of the company it used to be. That said, I’d actually argue there’s an evolutionary explanation behind this where at a certain size, and more importantly complexity, an oversight like this becomes even more likely, not less.

> First of all, Google is a shell of the company it used to be.

Isn't that squarely at odds with Google's supposed AI prowess? Is the rot really so severe that their advances in AI (including things they've yet to make public) are insufficient to overcome it? Or are the capabilities of Gemini and AI systems in general being oversold?

Post reply on HN