I have no interest in authenticating my clients as they are.
I do, however, want to make sure that anyone reaching my FireBase is authorized. Namely, that it's only via my Android app.
Could it be done somehow? I couldn't find any option or alternative in FireBase documentation.
The best approach I see is to have my app signed by a certificate, and aithorize itself using it.
To authenticate your app, use FCM (but regretably, it requires a server code):
Create an anonymous firebase account.
send an FCM message to your server, with the firebase account uid.
the server will create a node such as /uids/$uid/enabled.
have a rule to require it, e.g.:
".read" : "root.child('uids').child(auth.uid).child('enabled').val() == true"
The reason for the FCM message, is that in order to send such a message, the app should be "registered", which means the developer's signing certificate for the app is known. anyone attempting to send such an FCM message and not through your app will fail - even if someone re-sign (and probably modify) your app.
The drawback is, of course, you need your server to receive FCMs - which is very easy on the device, but harder on the server side.
Related
I had used fcm to send notification in my app using api.after some days google send this and removed my app from play store.please help me.
I have tried everywhere not getting exact answer.
Put FCM Key in untrusted environment is a security issue, Any hackers are possible to send message to any user by using FCM key.
FCM key shouldn't exists in your public app like downloaded to your instance, Store in local storage, Hardcode inside application etc.
FCM key should only exists in trusted environment like your server, cloud functions etc.
You can also see this Do I need to protect my firebase Server Key?.
Firebase admin is only available for admin or users also to send notification to other users?
Actually i am little bit confused in send notification from one user to another and which data is used like on the basis of user receiver uid or receiver fcm token.
firebaser here
Calls to the FCM API to send messages require that you specify the FCM server key in your code. As its name implies, this key should only be used in server-side code, or in an otherwise trusted environment. The reason for this is that anyone who has the FCM server key can send whatever message they want to all of your users.
So sending messages to users is indeed only possible from a trusted environment, either through the Admin SDK, or the REST APIs. See How to send one to one message using Firebase Messaging for more.
I would like to know how to secure your API authentication call/method in react-native from reverse engineering. Because I have the method to make a header value that goes with the authentication call and gets verified on server. But I don't know how to secure it.
There is no OAuth method implemented on server, while the previous app is build in cordova, in which they made the function in native android and access it through cordova, and I can't find such a way to do that in RN
You can use something like react-native-secure-storage or react-native-keychain to safely store your api keys in local storage.
https://github.com/oyyq99999/react-native-secure-storage#readme
https://github.com/oblador/react-native-keychain
If the server has properly implemented OAuth, you don't need to worry about reverse engineering.
The personal or client access token that you send with each request can easily be revoked on any kind of misuse.
I am designing a REST API in Laravel to be used with my ios app. Currently I am stuck on the following point: How to secure my REST API to allow access to ONLY my ios app?
I have read about HTTP Basic Authentication, HMAC, oAuth2.
1) Basic authentication requires SSL and it requires you to send the username:password on every api call.
But this doesn't stop others from using the API from other applications assuming they post their login credentials to the endpoints?
2) I understand the HMAC method and how the client & server both know of a Public & Private key. The private key is encrypted along with the request and other data. The public key is sent in the headers. When the server receives the request it detects the public key in the headers and associates it with a private key in the DB. It then recalculates the hash and checks if it matches. So, I have the following questions:
How does a newly registered user get the private key to be stored in the IOS app if the private key is not to be sent over the wire?
Is this more geared towards applications that will utilize your app? I normally see this in a API dashboard like Instagram & Facebook where they give you an app secret key, right?
3) oAuth2 - To me this seems more like allowing people to login to my app utilizing another API. For ex, allowing users to login to my app with FB and allowing my API to utilize Facebooks data? I am not really needing to do this at the moment.
am I misunderstanding this?
It sort of sounds like I need to incorporate something similar to the HMAC method by granting my IOS APP a private key where I store this in my IOS APP code. When a request is ran from within the ios app i pass along a hash with the private key and other data and then when the request is received on the server I detect if the request came from a user within the app by recalculating the hash. I have no idea if this is secure & I would assume it isn't?
What knowledge am I lacking? I am so confused at the moment that writing this question was a big struggle. I will revise it as soon as things become more clear.
1.
You're right, this doesn't prevent non-approved clients.
2.
This isn't really a way to prevent unapproved clients, it's more about verifying that a message isn't tampered with over the wire.
3.
You're understanding oAuth correctly, it's about authenticating clients to use your API in a specific way as well as limiting permissions.
It's not really possible to lock down your API so only a specific client can use it, because there's no way to verify who the client really is. Additionally, any form of authentication or verification done on the client side can eventually be be reverse engineered, and then can be sent to the server as an 'approved' client.
Something like this could be done with a token. The server sends a token the the client, the client performs some known operation on the token, such as salting and hashing, with a known salt and hash operation, then returning the token to prove that the client is a real one.
The problem is, if someone reverse engineers your client, they can determine what that operation is, and then create their own client which authenticates the same way. Any form of client side authentication isn't true security and can't be trusted.
Another way this is broken, is if someone can MiTM your request. The request could be captured and modified before it reaches the server, and there's not really any ways to prevent that from happening aside from using SSL, which can be broken with something like SSLStrip.
Any attempt to prevent a non-approved client is basically security through obscurity, since there isn't a provably secure way to do what you're asking.
The best way to protect your API isn't by limiting which clients can access it, but by making it secure already. Best practices would include forcing SSL, only send the password once and use tokens for authentication from then on, etc.
So I'm having trouble understanding something...
If you do Oauth for Web Apps, you register your site with a callback URL and get a unique consumer secret key. But once you've obtained an Oauth for Web Apps token, you don't have to generate Oauth calls to the google server from your registered domain. I regularly use my key and token from scripts running via an apache server at localhost on my laptop and Google never says "you're not sending this request from the registered domain." It just sends me the data.
Now, as I understand it, if you do Oauth for Installed Apps, you use "anonymous" instead of a secret key you got from Google.
I've been thinking of just using the OAuth for Web Apps auth method, then passing that token to an installed app that has my secret code embedded in its innards. The worry is that the code could be discovered by bad people. But what's more secure... making them work for the secret code or letting them default to anonymous?
What really goes bad if the "secret" is discovered when the alternative is using "anonymous" as the secret?
The main difference between OAuth for Web Apps and OAuth for Installed Apps (e.g. "anonymous"/"anonymous" as your consumer key/secret), is the approval page.
For installed apps, there is no way for Google to verify the identity of the
application so a yellow warning box is shown to the user saying so.
For web apps, there's an actual URL (of the app) that can be verified.
Hence, no ugly warning box is presented to the user.
The only thing you need to identify yourself when doing an OAuth call is the signature which is a HMAC-SHA1 string signed with your consumer secret. There's no relation with any domain whatsoever.
The only thing you need to keep reasonably safe is the consumer secret. I don't quite get what you mean by "anonymous" though...