| |
| ▲ | drawfloat 20 hours ago | parent | next [-] | | 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. | | |
| ▲ | orf 17 hours ago | parent [-] | | 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 13 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 13 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 16 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 16 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 12 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? |
|
|
|
| |
| ▲ | shepherdjerred a day ago | parent | prev [-] | | What exactly are you advocating for | | |
| ▲ | orf 17 hours ago | parent [-] | | Read the thread? > I think every API key system should have endpoint "invalidate_api_key" Not this. | | |
| ▲ | shepherdjerred 11 hours ago | parent [-] | | Yes, so you are against the proposed idea. What is your alternative idea? No idea why you’re being so hostile here. | | |
| ▲ | orf 11 hours ago | parent [-] | | 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. |
|
|
|
|
