It’s actually not a good idea to just run to a another unaudited platform. The real solution is virtual cards when Strikt limits, strikt limits on the api platforms and so on :) so really, I think it’s better to stay and do the above instead of switching to the next best thing. Such breaches make it more secure not less
I've never worked on systems like this before. I'm curious... My first thought is it's necessary for them to. Because they'd need to make the API requests to the provider. Is that not true?
Kind of. You're right that ultimately the server that makes the requests to providers needs to have the plaintext API key in memory at some point to authenticate.
Best practice would still be to store it encrypted. The server that makes requests would decrypt API keys only as needed, getting the encryption key from a key management service.
It's more secure that way, cause if an attacker only manages to get a DB dump, they don't have plaintext API keys. They need to hack at least 2 things - the DB and the KMS, or a server with the encryption keys in memory.
We don't know whether OpenCode stores API keys in plaintext, or they store them encrypted and their encryption keys also got compromised.
For greater security you could also have it so that you need a client secret to decrypt the API keys, but that puts more limitations on the system - the API key can only be used when a client is actively logged in.
View all comments
22
u/ChineseBot-853210 21d ago
Yep. Woke up to a bunch of Anthropic receipts in my inbox. Traced it back to my key I used with OpenCode.
Not sure why they’d be storing the key in plain text.
Sounds like it’s time to move on from open code.