Protect Firebase credential file Golang exe.

[akzainda11]

I'm building an application to run on computers (any architecture) using Golang. For my Golang exe to access my Firebase database I have to add this json credential file as seen in the image. If someone reverse engineers my Golang exe then it will be very easy to get hold of these keys and make fraudulent operations on my database. What is the best practice/method to prevent anyone from getting a hold of this json? Will it always be very easy to extract these keys? I'm not completely sure but I think it would be way safer to put this json on a server and then make the users golang apps post to my API after they auth, but the main purpose of firebase in my app is Snapshot Listeners which are meant to be real time. I'd appreciate some tips. Thanks. 

 

[jackyjask]

are you going to run your binary on cloud VM or on any customer PC?

[whoknows]

this is/was common problem from the beginning.. just create a new /view only/ user. In case the application needs also write access dont know!

[jackyjask]

well, if this is VM in the cloud - you don't need to provide full GSA json key

as any VM has metadata server that takes care of the IAMs

you just need to run the VM under correct (and limited) GSA, thats it

[akzainda11]

@jackyjask this golang app will run on any customer pc.

 

@whoknows My Firebase database has a collection named "users" where each document is for a specific user and the document id Is just the UID of the user. For this golang app that I'm making to run, it has to authenticate and the result of this is a uid. So the current user on this Golang app should only be able to read+write to `users(collection)->uid(document)`. The current user should not be able to access any other collection or document other than their own. I think you were suggesting to manage the permissions on the credential json, is the above specifications something I can enforce with permissions?

[atom0s]

Your application should absolutely never contain that file or any of its information anywhere in side of it or on your customers machines, ever. Your application should also never be making any kind of direct connection to your database(s) ever. This kind of situation is the exact purpose of things like web services that 'bridge' the connection between your application and your database(s). The application should be making requests to said web service asking for tasks to be carried out with the web service validating the request, any of the user input and then performing said task if it was valid. (ie. authentication / login, general CRUD operations, and so on.) Keeping in mind that your web service should be heavily locked down, restrictive and only allow attempted requests for authenticated users meaning that there should be an endpoint that must be used for to login/authenticate with the service before additional requests can be made. (The common approach to this is to have an auth or login endpoint that, if successful, returns some means of an auth token or session id that is used in all other web service requests. Be sure to read up on best practices with this kind of system for secure tokens, proper auth handling, secure password handling, proper session timeouts and rate limiting etc.)

[whoknows]

@akzainda11 ^exact as @atom0s said, u should use traditional API for authentication.. Firebase is to store common entities data (aka no need to worry if somebody browse the firebase data).

Edited January 9 by whoknows