Yes this is what I was asking about initially. I understand there are some security risks storing the users api key but there are also security issues when using the api key from the browser(local storage, session, etc.)
…What
@bloodlinealphaDev is discussing a “web app”. This was a topic that they revived a month later.
Also
Best security practices are still the same. Autofill for example is entirely clientside which can be considered almost the same as an environment variable. A website cannot “retrieve” your browsers autofill variables (while they can for local storage if they are the origin), the user needs to explicitly send it. It’s safe on your computer, but still needs to be sent out and processed.
No. No. Not at all. In this context (of API keys for other services) IF you are going to be storing valuable items it should be YOUR valuable items. It should be YOUR keys that you use to authorize your users. For the many reasons that have been discussed above. Storing someone’s API key is never “necessary”.
This honestly all blows my mind. Are you seriously suggesting that although you didn’t bother to read the actual conversation that they should store OTHER PEOPLE’S API keys?
But it is still associated with your service/website, you do not want to put the user’s vulnerable information (secret api keys etc…) in a situation where it could be exploited just to use your service. Even though its not your fault per say, it is a bad design. The user will still say “I used ‘xyz website’ and my api keys got stolen”. While there is technically less risk legally, it does not mean you are doing right by the user.
We will stay away from using user api keys for now, thanks for your discussion!
I understand what you are saying. I truly do. Yet, you are not understanding what is being said here. No, it’s not bad design. Look at all the other services that offer “BYOK”. First, they are almost always open-source and allow for self-hosting. BYOK in a closed-source solution in itself is bad design and practice.
Regardless, let’s recap both scenarios:
Option A: If an API key needs to be sent each time this narrows the potential attack vectors compared to option B. The key is sent, used, and discarded.
Option B: If an API key is stored in a database it still needs to be sent initially. Now you need to spend resources and space to store the key, authorize the user, and perform the transaction. Again, You still need to send out the key. I’m not going to again mention all the additional, not different, additional attack vectors you have exposed yourself to and haven’t addressed once.
In an event in which your website is compromised and the keys were retrieved you are still screwed, and liable. Another massive difference is that you have a known treasure trove sitting there, begging to be captured. Why not just open up a store and have a chest bursting with gold coins sitting right outside the window. But I have security bars!
I once was on a construction site for a gas station. Had a full inventory (including cigarettes), security bars, all the anti-theft deterrents possible. It was attached to a car wash. Near the end of the construction a group of people went into the car wash, broke the wall down, and stole all the expensive merchandise. You are this gas station
But, whatever. I have tried. I hope you succeed and I truly hope you are never a victim of a breach because it would utterly devastate you. I know you have “thank you, I won’t do that”, but the fact that you prefix it with “no, that’s bad design” just means to me that you just want to leave the conversation without taking in anything at all. I honestly do want to see you succeed, and maybe I’m trying way too hard, but I hate knowing that someone is starting a new business and is already potentially setting themself on a path to devastation.
Please. Get insurance for your business, for your own sake, and watch their eyes bulge when you mention that you are storing thousands of dollars worth of API keys for free users.
See the last line of my message? “We will stay away from using user api keys for now, thanks for your discussion!”
I appreciate the discuss, but we are getting way off into the weeds of design and you clearly have a very specific opinion, which is fine. This is not an open source or self hosted solution, it will be a monthly subscription service.
We understand the risks of both scenario’s and were curious if there was a way the for users, to use their OpenAI API key instead of buying tokens. Ideally there would be a way to authenticate with OpenAI, but that does not exist yet.
Again… We will stay away from using user api keys for now, thanks for your discussion!
Agreed. A one-time token would be nice or even third-party authorizations.
Well, most (good) boxing coaches have broken noses and worn out knuckles. (not saying that I’m a coach, if that’s what you get from that). Also, it’s not completely my opinion. It’s a collective thought that is contained in the link I posted earlier:
1 Like
You’re absolutely right. I would never want to store MY key on a client machine. However, it depends on what you’re developing. For a developer tool, the user should have their own key. Open source projects will also likely rely on the user having their own key. For programs aimed at users who typically don’t have an API key, other solutions are needed. Perhaps an API on my server for the OpenAI API. I haven’t worked out the details yet. I’ve been programming for decades, but not in a field where key management comes into play. Mostly backend processes in the financial sector. It’s definitely an exciting and interesting topic.
2 Likes
Thanks for the elaboration. Completely agree & have nothing to add
1 Like
Hmm, if the only problem is to save the API key locally in a safe way: the server has access to the browser cooky and to its contents, i.e. the keys can be saved encrypted in your browser on behalf of the server by sending encrypted cooky contents.
E.g. Ruby on Rails does this by default. That’s how user sessions are securely saved in general. Even the local user cannot retrieve these keys and decrypt them, only the server can, because the AES key for it is generated server side. If you don’t want the server to get hold of your credentials: remove the cooky from the browser cache. Then you’d put into a form again the API key if you want to continue to use the service.
You could generate a unique AES key for each user and just save that information server-side together with the usual user records.
I admit I only skimmed through this conversation, so forgive me if it was already clarified. But, isn’t the whole “bring your own key” idea contrary to OpenAI terms of use? I mean, no matter how secure the key is, isn’t this explicitly prohibited by OpenAI?
I’ve been building a system to track and bill tokens used simply because I can’t require users to bring their own key.
1 Like
Yep,
Stated right here in the thread actually.
In the context of the recent discussion, completely. For obvious reasons.
But, for self-hosted open-source solutions it’s not. For obvious reasons.
This may be obvious but I think it should be clarified.
That was September 2022 and now the linked guidelines no longer include any references to API keys whatsoever. And the referenced App Review process is now defunct.
It would be great to have an updated response from OpenAI staff directly.
While there’s several places in the technical documentation and help articles where they strongly indicate that API Keys are private and should be kept secret, the Terms of Use don’t seem to prohibit “Bring Your Own Key” type solutions.
–
Don’t get me wrong. If your primary product is based on OpenAI’s API and it’s running through your servers (rather than so many of these ‘chat clients’ that run purely in the browser), you should be using your own API Keys, running them through the moderation endpoints, and rate-limiting and billing your users accordingly.
But OpenAI hasn’t outright said that Bring Your Own Keys is prohibited after all the changes they’ve made around the APIs, App Review process, etc.
There also hasn’t been any progress on making it possible for end-users to authenticate with their own OpenAI credentials (eg. OAuth) since the January '22 mention of such features.
1 Like
Now that you have to pre-pay for credits and there are no refunds, and OpenAI is not exposed to unwise use and people not wanting to pay for their own irresponsibility by shirking on bills: sure, go ahead, see what happens. 
1 Like
In the last couple of months people have been routinely banned for using it through websites that use have a BYOK model. Some say it is solely for the NSFW nature of the websites, but there is no confirmation of that. If you want to test your theory, you’re more than welcome. But there is pretty strong evidence not to do that.
Additionally, considering how young the ecosystem is, I’d avoid BYOK like the plague. Its super hacky method to onboard customers because you don’t want to pay the bill. It’s also super insecure. Currently OpenAI has like 0.001% (this is an exaggeration, idk but it sucks) response rate to customer support. If people want to live on a knife’s edge, they can, but once you are banned, good luck getting back on.
Whether it is side income, a fun project you put 20 hours a week into, or a business, I suspect if people think it over, they’d rather not risk their effort on a coin toss weighted with the evidence it’s not allowed.
Good luck, but as we say here in Vegas, the house always wins.
3 Likes
oh the famous last words “encrypted and safe”. Nothing is 100% safe 100% of the time
1 Like
Hello @ishant.singh ! Is there any update on this? Thanks!
1 Like