| Without more context it is hard to say. For example how often are you using their API Key? Who initiates using the key (e.g. customer, yourselves on schedule, yourselves but manually)? The password cheatsheet linked elsewhere isn't directly relevant, because an API Key needs to be stored in a recoverable way, unlike a password. A more relevant cheatsheet might be this one (Cryptographic Storage): https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic... Without more context or information I am making a lot of assumptions: My gut "go to" is store an entire SQLite single-file database in your regular database (binary/file column), and take advantage of SEE[0] AES-256 (OFB), SQLCipher, or one of the free/open source extension alternatives. Then encrypt/decrypt it using something derived securely from the logged-in user's password (not otherwise stored in the database) OR a mix of something user specific held in your database (e.g. UUID) + something secret stored in environmental variables/on servers. The result is that database compromise ALONE isn't enough to steal the user's secrets, you'd need server + database, or the logged-in user's original password. I realize a whole SQLite database for secret storage might seem excessive, but it is very scalable and self-documenting as you add additional secrets or elements to existing secrets. Most commercial database offerings offer encryption at rest, and a few offer table-specific encryption, but in my experience utilizing some of those implementations is actually MORE complex than what I'm describing here, even if you'd expect the inverse. [0] https://sqlite.org/com/see.html |