If you are providing a free service (because they can use their API keys) why would you want to carry such a liability? If you really want to give them the option of BYOK you should NOT save their keys at the very least.
No you don’t understand it’s encrypted and safe
This only makes me salivate more.
This doesn’t make any sense. You still are a middleman unless what you are offering is a front-end service that the user can host on their own computer and has no communication with your server.
You do realize what you are saying is conflicting? If you want to allow the user to “bypass you completely” why are you storing their API keys? You are clearly still the middleman except what you are offering is a free, dangerous, highly liable “store your key for free” service.
I am referring to the payment for the api costs. I would have to charge the customer in advance, then pay OpenAi for their api costs. Rather than the user, using their api key and they would be directly charged by OpenAi.
The API tier was going to be $5/month, which will allow you to use the app and tools. The API charges the user pays obviously, which would be variable depending on use, but is by far the cheapest option because it is pay as you. If have not spent more than a dollar, for a month, while testing.
I am looking to be efficient with payments because over and under charging does not benefit anyone, as all payments have a fee tied to them… so less payment handling benefits everyone!
I understand. You don’t want to tie them up in a payment plan for whatever reason.
What I am trying to say is that it’s a huge liability to store their API keys. Especially if they are not a profitable user.
Just consider the implications. You would need a database (not very important), but most importantly you would need some sort of authentication system to connect the user to their API key. That’s where things get interesting.
On the other hand you can just have them enter the API key as a one-time process. Use it, discard it, make sure it doesn’t stick around in your logs and you are safe.
I thought about this too, but that would involve storing it in the users browser, which I think is a bigger security risk, as I have no control over their clearing their browser storage. It may be picked up by other malicious sites.
I came to the conclusion that allowing the user to enter it and save it to the database, with the option to remove it whenever was the safest as it limits potential exposure points. That way it is only ever used on the backend…
Why do you think this? Where did you read that this is a security risk? Local storage is confined to the origin that it was created in. If this wasn’t true there would be havoc all across the internet.
I think you are over-thinking the situation. You don’t need to do anything at all. How do you think browsers can “remember” input fields when the page is refreshed, or auto-fill?
You need to read this before you decide to release your service:
No. Without even considering security practices just consider this: Do you want to assume responsibility of their keys? If you have 100 users with $120 API keys do you want to carry ~$12,000 worth of liability?
It is pretty common knowledge not to store sensitive information in the browser, it should always be handled server side. Yes the same-origin-policy prevent direct access but XSS attacks are still possible.
If your website is a victim of code injection you have some serious problems.
This doesn’t mean what you think it does.
Let’s say that this happens. What exactly prevents then the user from losing their account? If some attacker is able to steal information directly from the page, why stop at the key and not just take the login credentials?
Common browsers have the option to autofill usernames and passwords. You have nothing to do with the API key credentials. That’s the point I’m trying to get to you. You are not storing it.
Sigh Yes, J. I know of local storage. You have missed the point unfortunately. Please read better next time. I do appreciate you going at all angles like an angry hornet though. Please continue. I yearn for this. I’ve been humbled before and I hope it happens again.
Common browsers have the option to autofill usernames and passwords. You have nothing to do with the API key credentials. That’s the point I’m trying to get to you. You are not storing it.
From earlier:
You don’t need to do anything at all.
Even earlier
On the other hand you can just have them enter the API key as a one-time process. Use it, discard it, make sure it doesn’t stick around in your logs and you are safe.
I never said that the API key should be stored in local storage. I was just making a counterpoint to this comment:
It may be picked up by other malicious sites.
So, sure. In the case of an XSS then yes, it’s unsafe. So is their login credentials/session at this point so it makes no difference.
Ok I understand, but for the application to work we need a reliable access to the api key. We do not want the user to have to enter there API key with every request. So we would have to set the API key to the local or session storage, so the application has consistent access to the api key to make request. Again, potentially exposing the api key on every request made.
Agreed. That can be annoying. I think the issue here is the separation between LocalStorage and autofill:
LocalStorage is a web API that allows websites to store data in a web browser. This data is specific to a particular website (or “origin”) and can be accessed via JavaScript. It persists even after the user closes the browser and is visible to scripts running on the website, making it possible to share between sessions and page reloads.
Autofill is a browser feature that remembers user input for form fields. The browser manages this data securely, and websites themselves cannot access this information directly via any frontend API like JavaScript. The data is only filled in based on user action or permission, and it doesn’t get exposed to the website’s scripts.
So, to Javascript there is no difference between autofill, and the user manually entering their key. This is a higher-level function.You are not doing anything. You are not setting any variables, you do not care about the storage.
If your website is a victim of an XSS attack you are still screwed, regardless of whatever route you take. Surely if you try to weigh these two options one becomes much more obvious.
No matter what you do you are going to need to send sensitive data over to your server to process the text. Ideally, if you are offering this solution you would let the user run the software on their own hardware. Most people are against posting their API key to a closed-source solution.
The main difference is that instead of opening yourself up to a lot of attack vectors you are narrowing it down to a few that can be avoided with good security practices.
There’s no doubt that you, and I will expose potential opportunities of leaking private information. Sometimes through libraries we use, or just bad/overlooked errors in our code. The biggest difference is similar to how stores in high-crime areas operate. They make it very clear that they do not have any cash worth stealing. Most anti-theft, security systems are deterrents.
So if I see that your webapp offers a free trial and stores all these keys in the database I just see money. I know that if there is an exploit that your code has fallen victim to, I can potentially access your database and rob you blind. So a zero-day exploit releases and all your keys are stolen. What do you do? Say you’re sorry and tell people to delete their keys immediately?
So, yes, my opinion isn’t perfect either. There is no perfect solution. I build my applications with the expectation of being hacked/having data leaked. (I read your reply as being rhetorical so that’s why I answered like this). If it wasn’t rhetorical then you would simply process the request as normal, and not store the key anywhere.
But the point is it could be stored locally, and browser code uses the OpenAI api.
Consider ChatGPT. Huge code in the browser. When you submit, it uses a special model endpoint that handles conversation history server side, but otherwise makes a call similar to api.
Your project that never receives keys:
Your server offers the ui code, the conversation history, the prompting and personality, the functions. Getting just prompt and response from client code.
Your client code stores API keys locally, obfuscated. It makes the api calls direct to OpenAI.
There’s not a lot of benefit for you the developer in doing all this, but it is within the realm of possibilities.
This entire policy makes it more important to get the user to get their own key and store it on their own machines. Make them responsible for the policy and the bills not me.
I’m not against storing it locally. I think if we had to argue about it I would argue that autofill is slightly safer than LocalStorage only because Javascript doesn’t have immediate access to it (even though eventually both are equally processed and sent somewhere).
I said “this doesn’t think what you mean it does” because well, only Siths deal in absolutes (lol). Every web application needs to store some sort of data on the client-side that if compromised could pose a security risk. How else can an application verify a user. Even then, I was not suggesting to store anything. Leave out any sort of responsibility.
I’m just very against storing it in a database for the mentioned reasons. I especially dislike the argument of XSS attacks because
An XSS attack would be devastating even if the keys are held in the database
A user still needs to enter their API key in the first place
Lastly, if API keys, the actual direct API keys (even if encrypted, this is akin to a bank vault door, it just takes time) are leaked and exposed, there’s no killswitch besides telling the users to revoke their keys immediately. This is assuming the web developer even noticed.
It could be something much simpler as well, such as someone finding a flaw in the authorization system. Already decrypted, ready to go. Database/authorization systems open up a massive amount of potential security issues.
The discussion is somewhat confusing. The original poster even though it was a long time ago, only talked about an “application.” However, the discussion seems to explicitly revolve around web applications. Not every application that uses the API is necessarily a web application. In a desktop application, you can simply store the key in the user’s environment. If necessary, it can also be stored in an encrypted database.
Or maybe I’ve misunderstood the whole thing. I haven’t studied every word.
