Hacker News Reader

Comment by orf | Hacker News Reader

And the whitehack hackers finding keys should do what, exactly?

Unilaterally decide they should be revoked, without contacting the owner?

And that’s not malicious?

Given they found a secret key in a public place? No that’s not malicious and it would be odd for a serious organisation to be upset someone immediately invalidated it.

Are you really unable to imagine a situation where financial or physical harm is caused by a system abruptly being shut down by a credential revocation, triggered by a random person on the internet?

Be serious.

Other options available: ruin the company financially, violate the terms of service of whatever system it uses and get the organisation banned, access business/customer data.

If it’s that sensitive and there’s access keys accessible to anyone, it could end up much worse. Nobody said it was without inconvenience.

This is so stupid. It’s pretty simple: malicious actors will use it to do all of those, plus now they can unilaterally bring down a system via revocation.

Non-malicious actors using it to bring down a system via revocation are therefore indistinguishable from malicious actors. It’s by definition a malicious act.

That’s why it’s a stupid idea. Non-malicious actors should just contact the company and let them take action. It’s not for an outsider to decide the impact of a leak.

Revocation of leaked keys isn't a new idea, even Github offers it as an option. It's basic practice.

I agree, but that wasn’t the point at all was it

Yes it was.

Could you point to the part where I said revocation as a principle is a bad idea? Rather than what I actually said, which was that untraceable random third parties revoking your keys without any involvement likely isn’t a good idea.

Also GitHub doesn’t revoke the keys. The providers of the key take provider-specific actions, which may or may not be revocation.

So… yeah.

That’s your opinion and plenty of people in here have pointed out they disagree. It has nothing to do with people not being serious or being unable to envision a situation where it impacts an important system.

So it indeed wasn’t the point then?

Is that system made by a supervillain or a mad scientist? But such system can go amok for any reason. Anyway revocation is already possible by publication on github, telling to GPT or sending an email to webmaster.

Credentials published on GitHub are not automatically revoked - what happens is at the discretion of the provider, for precisely this reason.

For example AWS applies a “quarantine” policy that prevents some specific actions[1].

Allowing anyone to report a potentially compromised key is one thing, but allowing anyone to unilaterally revoke a token is another.

1. https://docs.aws.amazon.com/aws-managed-policy/latest/refere...

The alternative is that the key won't be quarantined and the attacker will be able to do everything. And quarantine still means denial of some service, e.g. ec2:StartInstances is denied, but ec2:StopInstances is allowed? So the attacker can shut down the system and you won't be able to start it again?

What exactly are you advocating for

Read the thread?

> I think every API key system should have endpoint "invalidate_api_key"

Not this.

Yes, so you are against the proposed idea.

What is your alternative idea?

No idea why you’re being so hostile here.

Can you point me to where I said I had an alternative? Or any rules that say you can’t discuss an ideas flaws if you don’t immediately have an alternative?

The status quo is clearly the local minima, given the myriad of trade offs and different parties involved.

Reply on news.ycombinator.com