I have an app published on the play store, I want to implement firebase in the app.
I have read all the documentation and I have two doubts:
If someone use apk decompiler with my app and get the googleservices.json, they can do whatever they want with the database?
It is possible that my database is secure without having the user logged-in?
I would appreciate any help
The fact that someone can read your googleservices.json doesn't involve security holes. If you configured your Firebase project correctly, you will notice that in the "Project Settings" panel there is a SHA-1 signature to add. If you add the signature of your debug/production keystore, only apps with the specific signature con use the data of googleservices.json to communicate with your Firebase platform. (If you decide to not provide a SHA-1, Google will use something else as identification mechanism as described here)
This question is not very clear. Your database is safe everytime. If your user is not logged in, probably he will not able to communicate with the database. Remember that a user should only be able to see it's own data, so if your app logic is correct a logged user shouldn't be able to see other peoples sensitive data. Moreover remember to not change the database/storage connection rules in the "Rules" panel like in the image below to prevent unauthorized operations:
Related
If someone wanted to reverse engineer my android application by getting the apk file and then customising it to do other things that it shouldn't do. Keeping in mind that the apk file will have the google-services.json file that we download from firebase when we create the firebase project to link the android app.
The question is:
Even though there is security rules on the real time database or firebase storage that only allows authenticated users. Then the hacker can reverse engineer the app and makes his own application that has the same google-services.json file and then when compiling the hacker can create an account and login to the app (which makes him authenticated) and then maybe he can delete and write data to the real time database.
Can someone please explain how the security holds then?
In general, you should assume that any code that you ship to a customer could be compromised. You should assume that the device that they're running it on is under their full control, and that they could change the way your code executes on that device. The issue isn't so much that your app gets decompiled, it's that you simply can't control the execution environment in any way (unless of course you manufacture the device and have built in your own hardware security).
The data in google-services.json is not private data. You should assume that the moment you publish an app, everyone will know all the information in that file. Think of that data as unique identifiers that tell your app where to get data. There are no passwords or credentials in that file that allow an attacker to do anything that you have not authorized them to do.
It's up to you to use security rules in conjunction with Firebase Authentication in order to control who can do what to the data hosted in Firebase. It's impossible to stop people from creating random accounts in your app, but it's possible to restrict what they can do.
If you find that your app is subject to some form of abuse, you can shut down the abuser's account, and also contact Firebase support to report abusive behavior.
I asked myself the same situation couple of months back.
As I understand, the moment you generate your project ( Creating it from Firebase console or Android studio) it will ask for a SHA-1 key.
This SHA-1 key is unique and serves as the authorization from your project to connect to the services of Firebase, for example, if a user has your google-services.json it will be hard to them to even log in or authenticate without a SHA-1 key that allows them to use your project.
I was also inspecting the google-services.json and there is the SHA1-1 with the package names.
"android_info": {
"package_name": "com.packagename.debug",
"certificate_hash": "SHA1-KEY"
}
If you need to add a new SHA-1 you will also need to either authenticate using Gmail to go to the Firebase console and add it yourself (in which case is nearly impossible that a hacker can access to your Gmail account) or do the same thing from Android studio and sync the project.
As I said before, this is how I understand this situation, also, little research from securing API keys told that you need to be worried about client-side APIs than public APIS in your app.
The thing is that encrypting client side your APIS exposes the encryption code and can be decoded to, this is why sometimes it will be better to run some sort of a function from Firebase and send the sensible APIS to your project.
Telling it again, I'm answering with how I understand it works from having and inspecting the projects that I have, this is not an official answer so take it with tweezers.
SO I recently discovered an old discontinued application of mine and I reverse engineered the apk since I lost the code.
Progaurd wasn't enabled, and I was able to successfully reverse engineer it.
This is a Firebase application, and in the strings.xml I was able to find:
firebase_database_url, gcm_defaultSenderId, default_web_client_id, google_api_key, google_app_id.
I'm trying to read from the database.
So, using my browser, I type in my URL [URL].firebaseio.com/.json, but I need a parameter, auth, which I would think is google_api_key, which I can get from strings.xml.
But, it doesn't work, and gives me "error": "Could not parse auth token."
So I think I need a different key, but what is it? Is it possible to find it using the decompiled app? All the variables are the same name as they were.
Note that this was probably created before the May Firebase update, so it's probably still using firebase.com, because there's no google-services.json anymore.
Unless the creator of the APK put a private token or password in the app (which they would not, unless they are intentionally doing something very insecure), then you would not be able to access the parts of the database that require authentication.
The google API key you are referring to is not private, and it does not grant anyone the ability to anything special with a project. It's merely an identifier for a project.
Im developing an android application for the first time (no prior experience whit coding....). Mainly the app is going to be used at work as a tool for service technicians. The app is almost ready for field testing, but there is one thing i need the app to do before that. I need the app to force the user to log in every time its opened. This is because some of the info on the app is confidential, and only people that currently works for the company is allowed to have this info. Whit firebase i can then block the users that leave the company, or users that are not verified. Currently the users sign in whit google and they stay signed in until they clear the app data or delete it.
I have looked far and wide for the answer to this, but i have only come across different use of timers.
If anyone has a better solution to this "safety" issue, im open to anything.
If you are using Google Sign-In for authentication, there is no out of the box support for forcing your user to authenticate with Google every time they use your app.
This makes sense, because the user is still authed with Google on your phone. A login system only authenticates the user; it doesn't inherently protect data stored on the device. As long as Google has a valid access token, the user won't have to type a username and password again (and simply clicking "login with Google" again doesn't really provide extra protection here).
If your primary concern is blocking access to users who have left the company, you should be covered if you are using Google Apps for your company. If you disable the user's account, their access tokens should become invalid. Google Apps admins can also manually revoke access to specific apps for specific users.
If you don't use Google Apps (e.g. your users are using #gmail.com accounts or accounts from a domain outside fo your control), you might want to consider implementing a list of users allowed to access the application, and verify the current user has access by checking that list via an API call on launch.
If the goal is really protecting the confidential information in the application, you might want to take an approach similar to Android Pay in which you require your user to set and enter a PIN number to access the application. As an added benefit, you can then use that PIN to encrypt any confidential data you are storing locally.
I will suggest you take a look into shared preferences and every time when the user is back into the app you send them to the login activity.
I'm developing an Android app which needs to be able to manage the user list. Problem is, Firebase doesn't seem to offer much support for this kind of scenario, as opposed to social apps where users are self-registering and managing their own accounts. I could create users in the Firebase console, but this is not enough.
The users are to be registered by email and password, some users must have admin permissions and be allowed to edit the user list, I can enforce this using security rules. However, the users listed in the Firebase console don't have any place to put extra information for the permissions, so this info must go in the main database. Editing the database tree in console is not reasonable, hence this must be done in the app.
First problem is, there is no way to get the user list from the app. As a workaround, I can create users only in the app using createUserWithEmailAndPassword() function. Then, I can save the extra user info in the main database, keeping them in sync.
Minor problems aside (such as newly created user getting automatically signed in, signing out the admin user), the function starts to fail and the error logs indicate "TOO_MANY_ATTEMPTS_TRY_LATER". This is not acceptable.
Any suggestions will be appreciated. Thank you.
The users are to be registered by email and password, some users must
have admin permissions and be allowed to edit the user list, I can
enforce this using security rules. However, the users listed in the
Firebase console don't have any place to put extra information for the
permissions, so this info must go in the main database
You should a separate worflow for admins which would add the admin UID to a DB node "admins".
Then whenever you need to check if your user is an admin using rules you can uses something like
".write": "root.child('admins/'+$user_id).exists()"
Creating and login in other users seems pretty unintuitive to me, I would suggest using dynamic links for invites and let the invited users, install the app, create their own users and sign in themselves. You can then use the dynamic link info to see whoever invited them and act accordingly.
Is it possible to build app whit integrated dropbox acc, and use this account for all clients? I want to upload images to dropbox, and all client apps can download it, or upload to this acc from my app?
I have read all dropbox sdk tutorial from there site, but steal not sure if this is possible.
Not really. DropBox uses OAuth for authorization to allow users to login with their own accounts. Even assuming you figured out how to log in on their behalf with your own credentials you would be handing out your credentials to anyone who wants them, allowing someone to change the password on the account, etc.
Alternatively I suppose you could generate tokens and hand those out instead, however you'd have to setup some sort of web service for this, and you'd still have problems with people being able to do stuff to your account that no doubt you don't want them to do. E.g. I could create an app that just instantly deletes everything that anyone uploads, or I could create an app that fills up your quota with files filled with zeroes.
This is not what DropBox intends you to use the API for (and in fact it may be against the ToS, you should probably read to make sure if you're going down this route despite my discouragement). You should use a more appropriate storage method.