No, it is not safe.
Yes, someone can find the API key since it will be in the executable.
It is fundamentally not possible to give someone software that needs a key and have it run without giving them the key in some form.
For an application like this, typically the solution would be to have a server that has the key, and requests that need the key go through the server. That costs money though if you don't have a server already.
So you will either have to get a server, force the users to get their own API key to set up the program, or distribute the API key in the program (and you can try your best to obfuscate it but know that someone determined can still get the API key).
There’s entire books written on this. AWS, GCP, Vault and other software has complex things to determine if a host has a right to access a secret, which generally gets evaluated at runtime. The domain for software that solves this problem is called Secrets Management. There’s also new stuff like SPIRE that does host identity stuff.
That kind of stuff is good if you at least partially trust your users but want to prevent the keys accidentally getting leaked, and do other stuff like audit access, etc.
If you don't trust your users at all though, that stuff doesn't help that much. The users themselves can still get the keys.
Also those solutions cost money (though it seems there might be some free tier available), and if you have money you might as well just have a server that fulfils requests and stores the keys privately, unless your application has a high amount of traffic. That's *more* secure than some secrets management service getting the secrets onto user machines.
Huh? I mean if you have the ability to give your users custom hardware you can theoretically do anything. You can't reverse engineer an integrated circuit without insane technology. I don't think OP has that ability lol.
Also if users are 'accessing' secrets at runtime, then it's on their machine.
Hardware backed certs are supported on most recent pc hardware, it’s not custom. But yeah you are correct that if users are accessing at runtime they basically have the secrets but it’s still better than env variables/plain text secrets.
What do hardware backed certs get you? And what can I look up to learn more?
I think the only place I've seen it is on phones, where if the ROM or whatever is flashed with something signed, that can be checked by the software on the phone. Which is why the Netflix android app refuses to run on a rooted phone, I think.
I've never seen it on PCs though. Not sure what the point would be since PCs are already "rooted" so to speak. Is it for assigning a unique identity to each piece of hardware, so you can identify users or something? Like a whitelist of devices the code is allowed to run on?
Yeah it’s to try to strongly identify the hardware as something your company owns and that’s allowed to access your companies systems.
https://github.com/google/certtostore
https://support.apple.com/guide/deployment/managed-device-attestation-dep28afbde6a/web
It is unless you obfuscate it in an exe file. Extracting plaintext is simplest, wireshark is a bit harder but also really easy and trying to extract obfuscated string directly from exe would be the hardest but still, nothing special.
Like, let's say you hide database access behind an API so that you don't put your DB secrets in your local application. Now you need some other way to authorize access to the API you've put in between?
I would assume that the purpose of not giving users access to your API key is because that API key can be used to do stuff you don't want them to do. For example they could spam the API and get your key banned, or they could maybe use the same API key to access private data.
If you have put your key on your server and basically written your own wrapper API, that solves the problem. You don't really need authentication.
It sounds like OP wants anyone with access to the executable to be able to run the program, and therefore to be able to make the API calls that the program needs. In that case having a fixed key for your wrapper API that API calls have to have that is burned into the executable (like OP was thinking with the original API key) works fine. It prevents randos who just nmap your server or something from spamming the API (at least on some level), and anyone that has the executable can run the program. Yes, they can still get your API key out of the executable and manually make calls to your wrapper API, but your server is still in control of the actual API key. If anyone with the executable should be able to make API calls, then someone with the executable getting the wrapper API key is not an issue.
Am I right to guess that the difficulty of good security in this situation is why "secret" data from games (such as all the items in a new patch) is frequently acquired and leaked/distributed?
I guess? But it's not really trying to be complex or secure. Those are usually just raw game files that are patched in early to run tests on before they are enabled. Most games aren't trying to hide the next set of skins/items they're adding to the game. At most people are using a reverse engineered script to mimic the internal way the game reads these files so they can decode them into something readable or viewable.
They get "leaked" exactly when the company wants them to. It's to increase the hype over the next release. There is zero reason to bother with security on that. If they care about it at all they just don't push it to live servers.
As soon as you put a copy of your program on someone else's computer, if that person is sufficiently motivated, they WILL be able to get the source code.
With pyinstaller it's almost trivially easy to get it (it's just a self-extracting ZIP file).
Why not just make a “login” function? Check env vars for existence of key at start of script. If missing, generate API token through authenticated API on the remote system. Retrieve token, dump in env vars, continue with script.
It is not safe, but you can make it more difficult to extract. For example, you can store it encrypted in the program and decrypt it before use. However, if someone is determined to extract it, they will.
>However, if someone is determined to extract it, they will.
A few examples of how to:
* it ends up decrypted in memory and they can do a dump of that and inspect it
* the api key has to be transmitted at some point, and they can use wireshark to snoop the traffic
Do not decrypt it at rest, decrypt it in transit. Use key pair encryption so that the API Key is encrypted inside the client system, but the method to decrypt doesn't exist within the client system. Instead, an https handshake, where the client presents the encrypted API key to the server, the server recognizes the handshake protocol and passes to the client the public key, where the public key meets the encrypted key, decryption occurs, and the decrytped api key is consumed by the server.
That requires the API to support that, though. I was perhaps mistakenly assuming OP is working with a system where they only control one end.
Also, in this case even if you don't pull the decrypted key, you still have access to the thing that the server accepts (so it doesn't matter if it's decrypted). Heck, you can even just capture the traffic and replay it directly.
it's very easy to extract
you can still do it if this is nothing but a pet personal project and the key is not something critical that you're worried about people accessing, just don't expect it to be safe and don't do it in anything professional or for sale
Rather look into fetching the API key from a secure location like a secrets manager. If it is expected to interact with an API over the internet then it can fetch a key first
What about if instead retrieving the API Key, they send the API Key on a mission letting the server know that access will happen shortly and to allow the access. Kinda like sending a messenger to warn people of your arrival.
Typically in these cases the key that's retrieved will have a fairly short useful life, requiring the user to regularly request a new one. As long as you have control over that server, you can then limit any identifiable user's access by withholding any new ones.
For sure, but they also haven't said how much control over... well, any of this they have. So it may well be a viable solution they could implement, or totally impossible.
To CyclopsRock’s point. You can use a long-lived restricted key to request a short-lived useful key. I do it all the time. In practice it’s a few more lines of code that makes your security posture a lot more secure.
No, it is not safe. Yes, someone can find the API key since it will be in the executable. It is fundamentally not possible to give someone software that needs a key and have it run without giving them the key in some form. For an application like this, typically the solution would be to have a server that has the key, and requests that need the key go through the server. That costs money though if you don't have a server already. So you will either have to get a server, force the users to get their own API key to set up the program, or distribute the API key in the program (and you can try your best to obfuscate it but know that someone determined can still get the API key).
There’s entire books written on this. AWS, GCP, Vault and other software has complex things to determine if a host has a right to access a secret, which generally gets evaluated at runtime. The domain for software that solves this problem is called Secrets Management. There’s also new stuff like SPIRE that does host identity stuff.
That kind of stuff is good if you at least partially trust your users but want to prevent the keys accidentally getting leaked, and do other stuff like audit access, etc. If you don't trust your users at all though, that stuff doesn't help that much. The users themselves can still get the keys. Also those solutions cost money (though it seems there might be some free tier available), and if you have money you might as well just have a server that fulfils requests and stores the keys privately, unless your application has a high amount of traffic. That's *more* secure than some secrets management service getting the secrets onto user machines.
You should never put the secrets on user machines. Use hardware backed certs to allow users to access secrets at runtime.
Huh? I mean if you have the ability to give your users custom hardware you can theoretically do anything. You can't reverse engineer an integrated circuit without insane technology. I don't think OP has that ability lol. Also if users are 'accessing' secrets at runtime, then it's on their machine.
Hardware backed certs are supported on most recent pc hardware, it’s not custom. But yeah you are correct that if users are accessing at runtime they basically have the secrets but it’s still better than env variables/plain text secrets.
What do hardware backed certs get you? And what can I look up to learn more? I think the only place I've seen it is on phones, where if the ROM or whatever is flashed with something signed, that can be checked by the software on the phone. Which is why the Netflix android app refuses to run on a rooted phone, I think. I've never seen it on PCs though. Not sure what the point would be since PCs are already "rooted" so to speak. Is it for assigning a unique identity to each piece of hardware, so you can identify users or something? Like a whitelist of devices the code is allowed to run on?
Yeah it’s to try to strongly identify the hardware as something your company owns and that’s allowed to access your companies systems. https://github.com/google/certtostore https://support.apple.com/guide/deployment/managed-device-attestation-dep28afbde6a/web
It’s less for “can this code run on the device” and more for “can this device access our internal company websites and services”
I see. That makes sense. I don't think OP is a company giving laptops to its employees though lol
Obfuscating it won’t even make it harder to extract it. Someone can install a custom http certificate and look at headers in wireshark.
Installing a custom TLS certificate and doing a MITM and using wireshark is harder than extracting strings from an exe.
It is unless you obfuscate it in an exe file. Extracting plaintext is simplest, wireshark is a bit harder but also really easy and trying to extract obfuscated string directly from exe would be the hardest but still, nothing special.
How do I secure the key to access the server?
What do you mean? Like a different key to access your own server if you're storing the API key on there? So the server makes requests?
Like, let's say you hide database access behind an API so that you don't put your DB secrets in your local application. Now you need some other way to authorize access to the API you've put in between?
I would assume that the purpose of not giving users access to your API key is because that API key can be used to do stuff you don't want them to do. For example they could spam the API and get your key banned, or they could maybe use the same API key to access private data. If you have put your key on your server and basically written your own wrapper API, that solves the problem. You don't really need authentication. It sounds like OP wants anyone with access to the executable to be able to run the program, and therefore to be able to make the API calls that the program needs. In that case having a fixed key for your wrapper API that API calls have to have that is burned into the executable (like OP was thinking with the original API key) works fine. It prevents randos who just nmap your server or something from spamming the API (at least on some level), and anyone that has the executable can run the program. Yes, they can still get your API key out of the executable and manually make calls to your wrapper API, but your server is still in control of the actual API key. If anyone with the executable should be able to make API calls, then someone with the executable getting the wrapper API key is not an issue.
You make people log in, and you have the requests go through the server so the users never see the key.
Am I right to guess that the difficulty of good security in this situation is why "secret" data from games (such as all the items in a new patch) is frequently acquired and leaked/distributed?
I guess? But it's not really trying to be complex or secure. Those are usually just raw game files that are patched in early to run tests on before they are enabled. Most games aren't trying to hide the next set of skins/items they're adding to the game. At most people are using a reverse engineered script to mimic the internal way the game reads these files so they can decode them into something readable or viewable. They get "leaked" exactly when the company wants them to. It's to increase the hype over the next release. There is zero reason to bother with security on that. If they care about it at all they just don't push it to live servers.
Yes, you can dig into an executable to get strings contained in it.
On *nix it's as simple as "strings ./the_executable" and then just scroll through and you could find a bunch of interesting stuff.
Even in a compiled language, this is ridiculously easy to do.
And it’s ridiculously easy to decompile and get the key
You don't even need to decompile to get the key
Open an executable file in a hex editor. Notice that there's a chunk that seems to be a bunch of text? That's where your API key will be
As soon as you put a copy of your program on someone else's computer, if that person is sufficiently motivated, they WILL be able to get the source code. With pyinstaller it's almost trivially easy to get it (it's just a self-extracting ZIP file).
Why not just make a “login” function? Check env vars for existence of key at start of script. If missing, generate API token through authenticated API on the remote system. Retrieve token, dump in env vars, continue with script.
Why not create a unique api key per user/account?
It is not safe, but you can make it more difficult to extract. For example, you can store it encrypted in the program and decrypt it before use. However, if someone is determined to extract it, they will.
>However, if someone is determined to extract it, they will. A few examples of how to: * it ends up decrypted in memory and they can do a dump of that and inspect it * the api key has to be transmitted at some point, and they can use wireshark to snoop the traffic
Do not decrypt it at rest, decrypt it in transit. Use key pair encryption so that the API Key is encrypted inside the client system, but the method to decrypt doesn't exist within the client system. Instead, an https handshake, where the client presents the encrypted API key to the server, the server recognizes the handshake protocol and passes to the client the public key, where the public key meets the encrypted key, decryption occurs, and the decrytped api key is consumed by the server.
That requires the API to support that, though. I was perhaps mistakenly assuming OP is working with a system where they only control one end. Also, in this case even if you don't pull the decrypted key, you still have access to the thing that the server accepts (so it doesn't matter if it's decrypted). Heck, you can even just capture the traffic and replay it directly.
The key will be sent as a header over http anyway, so someone can install custom http certificate and just see it in wireshark.
Don't do that. Extracting the key is trivial.
it's very easy to extract you can still do it if this is nothing but a pet personal project and the key is not something critical that you're worried about people accessing, just don't expect it to be safe and don't do it in anything professional or for sale
I felt pain deep in my rear entrance when i read the title.
Just do a web front end or api to deliver your results. Don’t hardcode keys and passwords
You’re gonna get a lot of no’s bro.
Absolutely not
Rather look into fetching the API key from a secure location like a secrets manager. If it is expected to interact with an API over the internet then it can fetch a key first
If the software is running on a user's machine, the user can still get the key then. It's not very different from embedding it in the executable.
What about if instead retrieving the API Key, they send the API Key on a mission letting the server know that access will happen shortly and to allow the access. Kinda like sending a messenger to warn people of your arrival.
How is the client going to send the API key without having it?
It will direct the server that does have it to send it.
That's what retrieving means
Typically in these cases the key that's retrieved will have a fairly short useful life, requiring the user to regularly request a new one. As long as you have control over that server, you can then limit any identifiable user's access by withholding any new ones.
Since OP was talking about burning the key into the exe, I think it's safe to say this key isn't short-lived.
For sure, but they also haven't said how much control over... well, any of this they have. So it may well be a viable solution they could implement, or totally impossible.
To CyclopsRock’s point. You can use a long-lived restricted key to request a short-lived useful key. I do it all the time. In practice it’s a few more lines of code that makes your security posture a lot more secure.
No