5

If I save API keys to Flutter_secure_storage, they must be exposed in the first place. How could they be pre-encrypted or saved to secure storage without exposing them initially?

I want to add a slight layer of security where keys are stored securely, only to be exposed when making an API call. But if I have keys hardcoded then they are exposed even if only at initial app run. How do you get around this logic?

RobbB
  • 1,214
  • 11
  • 39

3 Answers3

2

To avoid exposing API key, you should store keys in a '.env' file and use flutter_dotenv package to access it while making API calls. Although this method will not help when making API call. If you really want to secure exposing keys, you should move the API calls to the backend so those network calls cannot be seen by the client.

Mohit Singh
  • 323
  • 4
  • 13
  • Good to know, I'll check out that package. I do agree backend would be best. Do you have any tutorials or resources for generating API calls to backend? I'm new to dealing with servers so this is a little confusing. I thought you needed the API keys to make any calls to your backend at all??? – RobbB Jul 21 '21 at 04:23
  • 1
    By backend, I meant creating a backend of your own and not using firebase or any other service. For creating your own backend you'll first have to choose a language for the backend, the best choice would be javascript since the language is similar to dart and you'll find lots of resources with it. You can watch this https://www.youtube.com/watch?v=uk-iRSj1Ldg for a basic understanding. If you're using firebase, there's no harm in exposing API keys as long as you've setup security rules to restrict unauthorized access. – Mohit Singh Jul 21 '21 at 06:42
  • I'll watch that video, good starting point. So I assume that the same goes for Parse? It is safe to expose API keys if I restrict access with ACLs and CLP? – RobbB Jul 21 '21 at 06:48
  • 1
    Yes. Firebase keys are safe to be exposed as they are used only to identify the project https://stackoverflow.com/questions/37482366/is-it-safe-to-expose-firebase-apikey-to-the-public. However it's not the case for all API keys. – Mohit Singh Jul 21 '21 at 11:18
1

If this is a web project, you could use something like base64 on both ends, then debase and save like this:

SERVER ON PHP

apiKeyEncoded = base64_encode(apiKeyGenerator());

CLIENT:

apiKeyEncoded = await getApiKey();
apiKeyDecoded = base64Decode(apiKeyEncoded).toString(); //this is the usable one, save it.

Now, if the project is focused on mobile use, I don't think you actually need to implement this, tho the code would be the same.

talevineto
  • 51
  • 4
  • Handy method, again as per my comment above, how do you make calls to the backend without the keys in the first place? I would really appreciate any help on this since I'm very new to dealing with anything server :) – RobbB Jul 21 '21 at 04:24
  • supposing you are using dynamic keys with an expiration time, first you would call the server asking for a key, it should respond with the base64 encoded key. Then you decode it and save to the device. Now, if your keys are static (always the same) then you can follow [Mohit Singh's advice](https://stackoverflow.com/questions/68449628/how-do-you-save-api-keys-without-exposing-them-in-the-first-place/68449747?noredirect=1#comment120996936_68449747#answer-68450042) . – talevineto Jul 21 '21 at 22:13
0

I will add some input to this. I am using Parse Back4App which exposes app API keys in the same way that firebase does. I have discovered a few very important security designs which may help with this.

Client side
Don't worry about app API keys being abused. Firebase/Back4App both have some security features in place for this including DoS & DDoS security features.

Move ALL actual API calls to server and call from client via cloud code. If you want to go to the extreme, create a user-device hash code for custom client rate limiting.

Server side
LOCK DOWN ALL CLPs, ALL ACLs, basically lock ALL PERMISSIONS and ONLY allow cloud calls with heavy security checks authorized access to anything server side including outside API calls.

Make API calls from your server only. Better yet, move your API calls outside cloud calls & create "cloudJobs", these run on schedule with Back4App and you can periodically call whatever API from server. Example: a crypto currency app might update prices once per second, once per minute etc. server gets these updates and pushes to clients. No risk of someone getting your crypto API keys and running the limits.

Put in a custom rate-limiting design & design around this so your rate limits would never trip under normal circumstances. If they do trip in excess, ban user & drop their requests.

Also put API keys in .env file on server. Go a step further & use a key encryption hardware service.

It would be a tell-tale sign that your server is compromised if your API keys get abused with this structure.

Want further DoS & DDoS protection? Mirror your server a few times and create a structure whereby client requests can be redirected under attack times or non-DDos/DoS attacking clients receive new app API keys.

... I could go on and on about security & what I've learned but I'll leave it at that.

RobbB
  • 1,214
  • 11
  • 39