Safely store an API client secret with Electron JS
Hi, I'm building a project with Electron, and I need to use APIs, since I want to make this app public, I must store safely my client secret and tokens
I know the existence of
safeStorage.encryptString(), and I played a little with it,
what I think I can do is encrypt my client secrete once, and since the returned thing is a buffer, convert this buffer to string, and then store it in a JSON for later
But my question is, how can I be sure a user will not take the encrypted token or client secret and decrypt it in his own instance of electron with safeStorage.decryptString() ?
I'm a little lost, and I want to be sure it safe but I really don't know a lot of electron and encryption
Thank you for your help22 Replies
I'm not familiar, but I assume that safeStore uses some kind of encryption that doesn't let you take the encrypted value and decrypt it with another application's safe store. But that point is kinda moot, anything that is on the client's computer will by definition be available to that client with enough effort and time
They can simply set up a man in the middle attack to decrypt your application's network traffic and sniff the API key
so there isnt any way to make it safely ?
The way to do it safely is have the Electron app hit your web server and the server do the API call
if you have to keep that key safe, the only way is to make your own API on a machine you control, and have your app connect to that api with their own generated API key. That way you can track usage, implement your own rate limiting, and revoke keys that abuse the remote API
the fuck that's getting hard
As Jochem said, anything on the client’s machine can and will be made public. Especially with Electron. JS is not compiled, it’s raw text that’s interpreted. And even with compiled languages there’s usually a way to “crack” secrets
yes, ok, i understand that
Yeah, security ain’t easy
do you know a way to host a server for free, cause i dont have any money
in some cases, security by obscurity can be okay, but the people you need to hide an API key from are other developers, and what I described isn't particularly hard for anyone with some sysadmin experience
If there’s nothing dynamic CloudFlare workers is a good place to start
yes of course
It’s “serverless” functions and the free tier has many thousands of daily requests
what do you mean by serverless ?
Also called lamda functions, they’re like on-demand functions instead of a server running full time
oh, nice
i'm going to check that
thanks a lot
Sure thing!
a question just came to my mind
because the cloudflare worker call will be in my code
i can get DDOS
It’s CloudFlare, anti-DDOS I’d kinda what they’re known for :p
but also: welcome to the internet
But yes, it’s possible
yes now that you say it
100 000 req / day, think it'll do the job XD
@13eck , just have a little question, i want to use a cloudflare worker, as you adviced me, but i cant use google api in it and find no solution for this, do you have any idea of how i could ?
quick quesiton, my youtube api client secret, must not be revealed , am i right ?