_mme

Exactly, that's the idea - having a backend part of the library that proxies the communication with OpenAI, keeping the API key secret.

Thank you!

This should be already possible, but it will give you a compiler error if you use Typescript. I will add support in the next version.

You don't! As mentioned in the README:

"Note: Don't expose your API key in public-facing apps. We will be adding a solution for securely using your API key soon."

I have ideas how to implement this, but I would like to get some feedback first.

I have to be annoying, but - if you have a token that is only valid for X seconds - you still need a token to renew the expiring token.

I have the feeling that damage control is the only option:

1) Secrets store is on different credentials

2) Decryption key is only known outside of secrets storage

3) There is a maximum number of different credentials that can be queried per day (adjustable over time)

Thank you, very useful!

> this is table stakes level security; realistically if your DB is compromised, your encryption key probably is too, because they probably got in through your application which holds the key in memory. this just prevents "oops I accidentally copied the DB somewhere and it leaked".

Good point. If the attacker gains access to e.g. a web service that needs to access the stored secrets, they will have encryption keys and DB access.

> if you have, or when you get to the point that you have, a competent ops org, just use HashiCorp Vault.

I watched a video about Vault, but I don't see how it would help. Attacker gains access to the web service which can access Vault -> Attacker downloads all API keys from Vault. Or is there something I'm missing?

Thanks, but this is about password hashing. I would like to know about storing third party customer secrets, like API keys, in the most secure way possible.

Nice website though.