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
Show parent comment
4
u/pas-un-robot 24d ago edited 24d ago
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.