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

151–160 of 326 posts

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

#151

Post by qudent »

gib444 wrote: post #138
qudent wrote: post #83

In Google AI Studio, Google documentation encourages to deploy vibecoded apps with an open proxy that allow equivalent AI billing abuse - giving the impression that the API key were secure because it is behind a proxy. Even an app with 0 AI features exposes dollars-per-query video models unless the key is manually scoped. Vulnerable apps (all apps deployed from AI Studio) are easily found by searching Google, Twitter…

[flagged]

I think the fact that it is not possible to put hard spending caps on API keys might be ruled illegal by some EU court soon enough, at least when they sell to consumers (given the explosion of vibecoding end-users making some apps). When I use OpenAI, Openrouter etc., I can put 10 $ on my API key, and when the key leaks, someone can use these 10 $ and that's it. With Google, there is no way to do that - there are extremely complicated "billing alerts" https://firebase.google.com/docs/projects/billing/advanced-b... , but these are time-delayed e-mails and there is no out of the box way to do the straightforward thing, which is to actually turn off the tap automatically once a budget is spent. The only native way to set a limit enforced immediately is by rate limiting - but I didn't see params which made it safe while usable in my case.

(a legal angle might be the Unfair Contract Terms Directive in the EU, though plenty of individual countries have their own laws that may apply to my understanding. A quite equivalent situation were the "bill shock" situations for mobile phone users, where people went on vacation and arrived home to an outrageously high roaming bill that they didn't understand they incurred. This is also limited today in the EU; by law, the service must be stopped after a certain charge is incurred)

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

#152

Post by bob1029 »

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)

Tax ids were never meant to be used as a form of global identification. If you go look in a real bank core, you'll find this field does not have any uniqueness constraints.

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

#154

Post by bob1029 »

What are the chances this isn't intentional to some extent? This wouldn't be the first time we've traded downstream legal trouble for short term gains.

Making AI utilization appear to go up is the only thing that matters right now if you're in the boardroom at one of these companies. Whether or not that utilization was actually intended by the customer is entirely irrelevant. From here, the only remaining concern is mitigating legal issues which google seems to be immune to.

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

#155

Post by nl »

bob1029 wrote: post #154

What are the chances this isn't intentional to some extent? This wouldn't be the first time we've traded downstream legal trouble for short term gains. Making AI utilization appear to go up is the only thing that matters right now if you're in the boardroom at one of these companies. Whether or not that utilization was actually intended by the customer is entirely irrelevant. From here, the only remaining concern is…

Does anyone really believe something like this?

There's a long stretch from over optimizing a UI to something that is very clearly an error like what has happened here.

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

#156

Post by Nathanba »

qudent wrote: post #151
gib444 wrote: post #138

Earlier quoted context omitted.

[flagged]

I think the fact that it is not possible to put hard spending caps on API keys might be ruled illegal by some EU court soon enough, at least when they sell to consumers (given the explosion of vibecoding end-users making some apps). When I use OpenAI, Openrouter etc., I can put 10 $ on my API key, and when the key leaks, someone can use these 10 $ and that's it. With Google, there is no way to do that - there are ext…

let's hope it happens soon, I'm pretty sick of this reality where companies get to charge you whatever they want and it's designed to always be your fault

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

#157

Post by ceejayoz »

ZiiS wrote: post #139

Unrestricted API keys were always secrets. They are created on a page called "Keys & Credentials". The fact that Google even allows unrestricted keys to be created has been a long standing security problem. The fact their docs encouraged it remains unforgivable.

Public keys are a thing in computing, though?

Google Maps has one, even. And Stripe.

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

#158

Post by nl »

charcircuit wrote: post #79
grey-area wrote: post #75

Earlier quoted context omitted.

Maps keys are always public in js on the website (but locked to use on certain domains). That’s how they work.

It is not actually locked to a site is just based off the host header. Which is public information an attacker can use to make the requests.

Sure, but the practical form of this attack is limited.

You can't maliciously embed it in a site you control to either steal map usage or run up their bill because other people's web browsers will send the correct host header.

That means you can use a botnet or similar to request it using a a script. But if you are botnetting Google will detect you very quickly.

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

#159

Post by simoncion »

franga2000 wrote: post #95
decimalenough wrote: post #43

Earlier quoted context omitted.

The Gemini API is not enabled by default, it has to be explicitly enabled for each project. The problem here is that people create an API key for use X, then enable Gemini on the same project to do something else, not realizing that the old key now allows access to Gemini as well. Takeaway: GCP projects are free and provide strong security boundaries, so use them liberally and never reuse them for anything public-fac…

Isn't there a limit to the number of projects you can make and then you have to ask support to increase it?

There is, yes. The rumor mill suggests that the default limit is 30.

At $DAYJOB, we had a (not very special) special arrangement with GCP, and I never heard of anyone who was unable to create a project in our company's orgs [0].

Given how Google never, ever wants to have a human do customer support, I expect a robot will quickly auto-approve requests for "number of projects" quota increases. I know that's how it worked at work.

[0] ...with the exception of errors caused by GCP flakiness and other malfunction, of course.

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

#160

Post by simoncion »

RobotToaster wrote: post #146
bob1029 wrote: post #135

Earlier quoted context omitted.

Out of all of the cloud providers, I find Microsoft's authentication stack to be the most legible and stable. Everything else really sucks though.

You know things are bad when Microsoft is the most stable...

As someone who has used very many "cloud providers" (including GCP, AWS, and Azure), it cannot be said that Azure is the most stable. GCP is far better for stability and reliability than Azure.

The extensive experience with Enterprise Authentication that the decades of use of Active Directory has given Microsoft may mean that their SSO and Enterprise Authentication stuff is the best out of those on offer. I wouldn't know about that... I just made (and destroyed) VMs and was often driven to frustration whenever Azure failed to reliably perform that simple task.

Post reply on HN