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

201–210 of 326 posts

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

#201

Post by abustamam »

Havoc wrote: post #167
KomoD wrote: post #162

Earlier quoted context omitted.

> Someone on the Google subreddit did report getting a 80k bill yesterday from a Gemini key. Do you have a link?

https://www.reddit.com/r/googlecloud/comments/1reqtvi/82000_... It’s pretty much a daily occurrence in all three of the big cloud subs that people still learning get wiped out because the clouds refuse to provide appropriate safeguards

Why spend resources on enterprise customers who have millions to spend on infra when they can just rely on obfuscation to make newbies pay hundreds if not thousands?

(/s, of course)

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

#202

Post by Terretta »

neop1x wrote: post #184

Many people wanted to be able to set a spending limit on google cloud account for many years but they were unable to implement anything, always suggesting a workaround by hosting a Cloud Run function which would remove billing from a project via API https://docs.cloud.google.com/billing/docs/how-to/disable-bi...

At scale, distributed API routing shouldn't call accounting transactions, that expands the availability risk surface and adds latency to all valid requests for no reason (other than helping the minority of companies/users who want their product to stop working when it is popular).

Distributed “shared nothing” API handling should make usage available to accounting, and the API handling orchestrator should have a hook that allows accounting to revoke or flag a key.

This gets the accounting transactions and key availability management out of the request handling.

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

#203

Post by AlexeyBelov »

zahlman wrote: post #119
lukeiodev wrote: post #103

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

You're replying to an LLM.

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

#204

Post by abustamam »

jascha_eng wrote: post #85
ryanjshaw wrote: post #51

Earlier quoted context omitted.

Seems like they ought to be dedicated security teams monitoring for exactly this: does a key to X give users access to not-X. Even more bizarre is their VDP team not immediately understanding the severity of the issue.

That's how you slow down development to a crawl

I don't see a problem with this. The problem with "move fast and break things" isn't the moving fast part, it's the trail of broken things that no one bothers to fix. When those broken things affect people's wallets, that's when we have problems.

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

#205

Post by abustamam »

827a wrote: post #12

Is the implication at the end that Google has not actually fixed this issue yet? This is really bad; a massive oversight, very clearly caused by a rush to get Gemini in customers' hands, and the remediation is in all likelihood going to nuke customer workflows by forcing them to disable keys. Extremely bad look for Google.

As I was reading it I didn't realize I was reading a security report, so I was like, is it responsible for them to be sharing this?

Then I saw the disclosure at the end and didn't get the sense that the flaw was fixed, so then I was still thinking... Is it responsible for them to be sharing this?

I'm glad that they did, because I can audit my own projects, but a bad actor may also be glad that they did.

The fact that we're hearing this first from a third-party and not from Google themselves is extremely problematic.

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

#206

Post by staticman2 »

petcat wrote: post #196
staticman2 wrote: post #194

Earlier quoted context omitted.

It is not. Legal fees are rarely awarded in the U.S.

I should have said if you recover it in your damages , which every competent attorney will push for.

Legal fees are not something you are usually legally entitled to.

Your attorney can push for whatever illegal thing they can think of, it doesn't mean you will get it.

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

#207

Post by abustamam »

bob1029 wrote: post #152
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.

Why not? Two people with the same tax ID seems like a problem waiting to happen.

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

#208

Post by semiquaver »

This is just embarrassing. It doesn’t even really qualify as a security vulnerability, more like a fatal flaw in the system’s design. I can see why the team pushed back on fixing it, seems like a massive pain.

It feels like something that would happen if you outsourced planning to an LLM.

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

#209

Post by abustamam »

ceejayoz wrote: post #157
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.

It's been a while since I've used stripe but don't their keys start with sk_ for secret and pk_ for public?

I like that. Easy to tell if you should keep the key a secret or not.

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

#210

Post by abustamam »

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.

I can maybe understand unrestricted keys (OK, I can't, to be honest).

But the fact that permissions are not hardened at time of creation is bonkers to me.

Post reply on HN