1

I'm just starting to learn to code. Providing example code would be fantastic.

I developed a simple android application (native Java) using Firebase. I have several API keys hard-coded into the resources of my application. I read that it is better to store these keys on a server. I currently do not have my own domain or server, but I am interested in using Firebase Hosting to store these API keys.

I would appreciate some help setting up the foundation for storing and retrieving these API keys through Firebase Hosting. I am open to other suggestions if they are simple and secure.

Thanks!

jason kim
  • 13
  • 1
  • 4

2 Answers2

4

Your (mobile or web) clients should never include the Secret for your Firebase. At some point somebody will reverse-engineer your code, extracts the Secret and with those be able to read/write all data in your Firebase database. The only thing you'll be able to do at that stage is revoke the Secret, which will make all clients fail.

Firebase hosting allows you to store static resources only. So while you can store your API keys on Firebase's hosting servers, it wouldn't help much for security. It will still be readable by everyone.

What you should instead be doing is using regular Firebase authentication in your clients. This is covered in Firebase's guide for user authentication on Android. A good example of this can be found in the Firebase Login Demo for Android.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Hi Frank,thanks for the clarification. I guess I misunderstood how to leverage the Firebase user authentication. I have been using it for google and facebook oauth's and have been storing my api keys on my firebase authentication manager. I'm assuming now that this is safe practice. Then is hardcoding my firebase url in the app java code considered safe practice? – jason kim May 20 '15 at 21:58
  • Storing your Facebook and Google auth keys in Firebase's dashboard is totally fine. Only you have access to that dashboard. Storing *secret* keys in your app is in general not a good idea. I'm now uncertain about the actual thing you are storing in your app's code. Can you edit your question to include a snippet of the variable and how you use it? Feel free to blank out the value, I'm just trying to understand whether we're talking about public keys (which you need in your client) or private keys (which you should never have in your client). – Frank van Puffelen May 20 '15 at 22:49
  • Firebase ref = new Firebase("https:\\blahblahblahnotreal.firesbaseio.com"); // that is used to establish a connection with my firebase account. Or in the "firebase login demo" example, in the keys.xml resource, there are the listed the API and Secret keys. https://github.com/firebase/firebase-login-demo-android/blob/master/app/src/main/res/values/keys.xml – jason kim May 20 '15 at 23:07
  • Ah... I'll admit to never knowing which key/secret goes where. *blush* But if they're needed on the client, it doesn't really matter whether you keep them in the code or in a static file on Firebase Hosting. It wouldn't be more secure, since both are open to inspection by unauthenticated users. – Frank van Puffelen May 20 '15 at 23:46
  • 1
    Do I get this right? Is it a good solution to store third party API keys in Firebase Database or Firebase Storage and retrieve them at runtime? I'm actually looking for a solution about this problem. Does Firebase cache the database locally? Is that cache encrypted? – stsandro Feb 23 '17 at 19:40
-1

You could encrypt your API keys and other sensitive data. Here is a great article regarding that. The most sensitive thing is a password which will be used for a symmetric key generation. And it is important (yeah, the same issue again) to have not this password hardcoded in the code, but to calculate it in runtime. One of the good parts for its calculation is an APK's certificates data (Retrieve the apk signature at runtime for Android). This will probably make the work of a reverse-engineer a little bit harder. But dynamic analysis will help him/her get a secret key.

Server-side computation technique is also very usable here, especially in combination with the previous advice.

Thus, a part of the key is generated in runtime and another part is to be received from a server after successful user authentication. Just an example.

But the easiest way is to use commercial obfuscators that support string/dex-bytecode encryption like DexProtector

N.B. I am affiliated with Licel (developer of DexProtector)

Community
  • 1
  • 1
Ivan Kinash
  • 884
  • 7
  • 9