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

71–80 of 326 posts

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

#71

Post by brookst »

827a wrote: post #15
devsda wrote: post #6

> Leaked key blocking. They are defaulting to blocking API keys that are discovered as leaked and used with the Gemini API. There are no "leaked" keys if google hasn't been calling them a secret. They should ideally prevent all keys created before Gemini from accessing Gemini. It would be funny(though not surprising) if their leaked key "discovery" has false positives and starts blocking keys from Gemini.

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.

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

#72

Post by brookst »

SlightlyLeftPad wrote: post #28
louison11 wrote: post #19

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.

I don’t see it.

Imagine for a moment the there is no oversight. Every intern can ship prod code with their own homemade crypto.

How do you, in a retail business, agree to accept credentials that anyone can mint for free?

I mean obviously it happened. But… this doesn’t even seem like a compliance mistake. It’s a business-level mistake.

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

#73

Post by carlmr »

brookst wrote: post #72
SlightlyLeftPad wrote: post #28

Earlier quoted context omitted.

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.

I don’t see it. Imagine for a moment the there is no oversight. Every intern can ship prod code with their own homemade crypto. How do you, in a retail business, agree to accept credentials that anyone can mint for free? I mean obviously it happened. But… this doesn’t even seem like a compliance mistake. It’s a business-level mistake.

If you've never worked in a large corporate environment you don't know how stupid things become. In a perfect bureaucracy nobody thinks.

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

#74

Post by edoceo »

rezonant wrote: post #55
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…

Imagine enabling Maps, deploying it on your website, and then enabling Google Drive API and that key immediately providing the ability to store or read files. It didn't work like that for any other service, why should it work that way for Gemini. Also, for APIs with quotas you have to be careful not to use multiple GCP projects for a single logical application, since those quotas are tracked per application, not per…

Really? I make multiple GCP projects per app. One project for the (eg) Maps API, one for Drive, one for Mail, one for $THING. Internal corp-services might have one project with a few APIs enabled - but for the client-app that we sell, there are many projects with one or two APIs enabled only.

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

#75

Post by grey-area »

charcircuit wrote: post #69
klooney wrote: post #36

> Retroactive Privilege Expansion. You created a Maps key three years ago and embedded it in your website's source code, exactly as Google instructed. Last month, a developer on your team enabled the Gemini API for an internal prototype. Your public Maps key is now a Gemini credential. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill. Nobody told you. Malpractice/I can't…

Maps keys should not be made public otherwise an attacker can steal them and drain your wallet and use it for their own sites.

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

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

#76

Post by IanCal »

charcircuit wrote: post #69
klooney wrote: post #36

> Retroactive Privilege Expansion. You created a Maps key three years ago and embedded it in your website's source code, exactly as Google instructed. Last month, a developer on your team enabled the Gemini API for an internal prototype. Your public Maps key is now a Gemini credential. Anyone who scrapes it can access your uploaded files, cached content, and rack up your AI bill. Nobody told you. Malpractice/I can't…

Maps keys should not be made public otherwise an attacker can steal them and drain your wallet and use it for their own sites.

It’s been years but I thought I recalled having to use the key but then also setting what sites it’d work on.

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

#79

Post by charcircuit »

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

Earlier quoted context omitted.

Maps keys should not be made public otherwise an attacker can steal them and drain your wallet and use it for their own sites.

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.

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

#80

Post by charcircuit »

IanCal wrote: post #76
charcircuit wrote: post #69

Earlier quoted context omitted.

Maps keys should not be made public otherwise an attacker can steal them and drain your wallet and use it for their own sites.

It’s been years but I thought I recalled having to use the key but then also setting what sites it’d work on.

If an attacker can figure out what sites it can be used on, they can use the API.
Post reply on HN