I'm currently looking at an .apk for Android and I came across some hard-coded credentials (email address and password). Apparently these are used for something called FirebaseAuth, which seems to be a Google service.
I'm not very familiar with the Android app development and don't know what the Firebase service is exactly used for.
Is it common to save hard-coded credentials for the service in the app?
What can be done with the credentials?
The credentials do not reflect any information affiliated with me.
I did come across this stackoverflow post, stating something about identifiers, but no clear answer.
edit: I believe my OP was not clear enough.
My question is whether it is normal for Firebase credentials to be stored in an APK or if generally something like an API token should be used.
Usually hard-coded credentials are a bad sign, but I'm not familiar with Firebase.
when setting up Firebase you get a bunch of configuration entries. These are only for in app use and are not related to any user. Your app uses them to connect with the Firebase services. Normally they are stored in a config file within your Android app. So it is totally fine when these credentials are hard coded.
In order to provide a better answer please include some more information about the credentials (f.e. format)
Related
My end goal is to keep safe my API credentials and that cannot be discovered by decompiling the apk.
Currently, my API credentials are hardcoded at buid.gradle(app module) file.
When I decompiled my own apk using this site I can able to find the API url and other credentials.
Now I am looking for a solution and more interested to know how "google-services.json" file is getting parsed.
If there is a solution to read **my-cred.json** file under app folder at runtime or compile time (the same directory where **google-services.json** exists), I think I can protect my credentials from decompiling the source( correct me if I am wrong)
Please tell me a way to read **my-cred.json** or any other solution to protect the app credentials
In my opinion there is no way to protect this kind of private keys on your Android device. So the solution is simply not to store it on the Android device. But you can store it on an external server. In my case this key is used onyly once per session, to generate a session token. So I simply created a small java app that create the session token from the user id and the api key. That app is hosted on Google App Engine, but any hosting service should do the work. Then your Android app has to invoke this app (servlet) to get a proper token, which is then used to invoke the API.
I know this does not directly answer your question - but it's quite simple to put in place and will avoid your key to be reverse-engineered.
This is only a partial answer, but before you get into complex obfuscation methods, I would recommend you to first check for each API how they actually authenticate your app: Most API services today require you to register the certificate of your app to work, so even with your API key, one wouldn't be able to use the quota of your app since one wouldn't have access to the private key used to sign your app.
After some research i found out you can't reliably hide an app credential into an android app. Several solutions are being described but none of them is 100% secure , as it is pretty easy to reverse an android app.
You can only obfuscate to make an attacker loose time...
Here are some ways to obfuscate your app credentials , but none of them are really secure even the C++/JNI one. https://rammic.github.io/2015/07/28/hiding-secrets-in-android-apps/.
Only way to have it 100% secure is to set up your own server to hold the credentials and do the login for you, or even requests. I think the best way would be using an OAuth2 authentication process.
It depends on the time you have and your security needs.
I have a project where one app needs to access multiple databases sharded across multiple firebase projects. Now since it's the same app, i can't use the same SHA1 across all the projects where i add the app.
I do not add any google-services.json files for any of the projects, instead i fetch the database url, the storage bucket info, the api-key and the appids for each project from my own server which keeps a track of all the sharded firebase projects.
My question is, with just this much information, can anyone just authenticate to firebase?
There's no SHA1 protection so is my db even safe even with the auth!=null rule? (since anyone can initialize FirebaseApp with this info and get a FirebaseAuth instance and sign in anonymously). In summary for this one, can anyone just make an app of their own, use the info and access/manipulate my database?
How can i secure my app if it's not secure with the current configuration
Yes, that should be enough information to create a web app that connects to your database.
But this should not be a problem if the database rules and auth providers are the right ones for your case. For example:
If you don't want anonymous Users to authenticate with your app, disable the option in the Firebase console.
If you want to give access only to a limited set of users without enabling new signups (or if you have special requirements for auth) then user a custom auth provider.
If you want to limit access to certain parts of your database (or need different user roles) adjust your database rules.
I hope that answers your question!
After a little research and a little brain storming, i came to the conclusion that Oauth domain which by default is localhost and the firebase-app domain will prevent anyone from directly authenticating to my Firebase app.
Even if the api-key and other info is exposed, as long as the service-account is hidden, the auth-domain will protect my app since the auth-domain will cause the authentication from a non-authorized domain to fail. Maybe I'll even want to remove the localhost in production :)
The title doesn't really indicates what I mean:
I am searching for a secure way to save user data (a point system for a game - under no circumstances the user should have the ability to change his amount of points). And I stumbled across firebase, which seems pretty nice and easy.
But:
If I give the app the rights to directly write the users new points to the database it is pretty insecure, right? I mean, someone could decompile the app and get the keys from firebase so that anyone could write to the database, or am I wrong?
Also, what would be the best way to save those "new point" into a firebase realtime database?
Edit: I am already securing my app with pro-guard but that just makes it more difficult for users to get the key, I guess.
The Firebase configuration data in your app is not a security concern. It is simply information that your app needs to find its Firebase project on the servers. See Is it safe to expose Firebase apiKey to the public?.
To properly secure data you write security rules, which are evaluated on the server. With these you ensure that users can only read the data you want them to and that only authorized users can make valid changes.
In cases where security rules become more complex than is feasible, you can consider proxying the read/write through Cloud Functions for Firebase. With Cloud Functions your code runs on Google's servers, so you have to worry less about user modifying the code for malicious purposes.
its secure if you use cloud code. This way everything is going through the server to save it and a user has no way to change that unless they have access to your cloud code.
I am thinking about writing an iPhone/Android app which will, among other things, send emails. I would like to, in some cases, provide my own mail server as an option. This of course means I would need to store some sort of credentials in the app to connect to the mail server. But then someone could conceivably reverse-engineer my app and get the password from the executable, which would be bad. What are my options here, is any, so that I could provide some sort of authentication with the app, which would be truly secure?
You can still go with storing the credentials with the app, though make it more secure. You can do this by splitting the strings you store then encrypting them. This will make it harder to get the plain credentials from the executable.
Fair warning though: with this approach you can only make it harder (more obfuscated) for someone to get them. They can still figure it out. Although you can make it very very hard.
If you are going fully native, mobile languages account for the need to remember credentials. Here are some starting points.
For iPhones: iOS: How to store username/password within an app?
For Androids: https://developers.google.com/identity/smartlock-passwords/android/store-credentials
If you aren't going native, you must also consider what server-side language you want to use and consider methods there (store a device identifier like MAC address, a generated key file on original login, and a username)
Please excuse my stupidity but is it possible to use something like OAuth2 so that users can log into my app securely even though the app doesn't use any features of Facebook or Google+ etc. So simply I just want something to authenticate my users.
My app makes calls to a database server but currently I have no security what-so-ever and I haven't got a clue as to what to even google for. I want to hold encrypted passwords for the users on the database and pass back some kinda of token to say they're now logged in, but I don't know how to go about this and just wondered if there was something more simple?
I had a long read in the threads here at stackoverflow. I would recommend having a read through this one. If you read the post, what you are looking for is a two-legged authentication, since you already trust the application (your own) you can trust it with the username and password. So, all you need is to authenticate those with your own database at the server and provide an access token to the user.