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.

▲

drawfloat 14 hours ago | parent | next [-]

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.

	▲	orf 14 hours ago \| parent [-]
		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.

▲

GoblinSlayer 17 hours ago | parent | prev [-]

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.

▲

orf 17 hours ago | parent [-]

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

	▲	GoblinSlayer 13 hours ago \| parent [-]
		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?