We are using IBM Push-Notification service and Mobile-App-Security on our Bluemix app (serving iOS clients).
In order to send a push notification, our server sends a POST request to: https://mobile.ng.bluemix.net/push/v1/apps/{application-id}/messages
with the application secret in the Ibm-Application-Secret header (following the instructions here).
To initialize Mobile-App-Security SDK inside our app you need both the application-id and the application-secret - this means that the app itself must contain these values (as constant parameters or download it from a server). If a malicious user fetches these values using simple reverse-engineering, he would be able to send the same POST requests, i.e. send push notifications to other clients, right?
Shouldn't there be two application-secrets? One secret for the app (making it hard to fake registrations - i.e. require reverse-engineering) and one for the server (which allows to send notifications and should never be stored on client-side).
Is it possible to initialize the Mobile-App-Security iOS SDK without an application secret?
I understand your concern. To address all your questions:
-You must have the app secret on the Client side in order to authenticate with MAS and use the Push service (Push relies on MAS auth)
-We recommend implementing your own form of security to prevent a malicious user from easily obtaining the App Secret. For example, encrypting the file that stores the app secret, or just the app secret itself.
If you are looking for a more robust built-in level of security, I would recommend using the newer MobileFirst Services Starter, with support for Push and the Advanced Mobile Access service (AMA), which is currently only available for iOS 8.
A mobile device registers with its unique device id at the server running on Bluemix. If you don't trust a device, you could send a push notification with a key to this device and request it back. If you get this key back, the device has also registered at Google or Apple successfully.
Related
Im trying to implement push notifications on Xamarin iOS project using Azure App Service Push, and I'm having problems with device failing to register.
The confusing part is this:
I've read https://adrianhall.github.io/develop-mobile-apps-with-csharp-and-azure/chapter5/concepts/
and it basically says that
The /push/installations endpoint is part of App Service Push - a feature of the Azure App Service resource. This exists on your .azurewebsites.net domain. It is not part of Notification Hubs.
However, according to this post:
https://blogs.msdn.microsoft.com/appserviceteam/2017/01/10/azure-mobile-apps-net-sdk-releases/
.AddPushNotifications() (which actually adds /push/installations endpoint)is now deprecated:
You should use the App Service Push endpoint instead. In your ASP.NET Owin Startup class, you can remove the reference to .AddPushNotifications() from the configuration.
Details here:
https://github.com/Azure/azure-mobile-apps-net-server/wiki/What-is-a-Default-Configuration%3F
If I understand correctly my App Service Mobile App, once connected to Push via Notification hub should expose some kind of endpoint for device registration but I find it unclear what that endpoint is and do i need to manually create it in mobile backend app?
.AddPushNotifications() is used to support the Azure Notification Hubs push registration endpoint via the Microsoft.Azure.Mobile.Server.Notifications package, you could check the NotificationInstallationsController.cs under the previous package. And at this point, you need to specific the Microsoft.Azure.NotificationHubs.ConnectionString app setting with the value for the connection string to your notification hub.
While the App Service Push is a feature provided by Azure Portal, and you need to go to your app service and click "Settings > Push", then choose your notification hub for your app, more details you could refer to here.
For your mobile client, you could leverage the extension method GetPush for IMobileServiceClient under MobileServiceClientExtensions.cs and the PushHttpClient.cs to send requests against push/installations for you. For more detailed code snippet, you could refer to here. Also, you could refer to adrian hall's book about using the .InvokeApiAsync() method.
I've set up Firebase to send push notifications to users of my app. However, I'm not sure what's best practice regarding user-to-user communication, such as chat clients. Should I get the device token at each startup of the app and use that for sending, or should I create a new topic for each "chatroom" that both parties are required to subscribe to? For instance when accepting a chat request.
If the first option is the best, how does this work? If the device is assigned a new token upon app startup, how can I be sure a given ID points to a specific device? The whole concept seems fragile - but could someone guide me to the most efficient solution?
I'm only looking to send chat messages / chat invites with push
Depending on the size and the privacy of the chatroom you can choose between using:
topics made for big groups, and without protections on joining / leaving
device tokens that you need to store in your server implementation.
On the plus side they allow you to control the who is receiving the
messages, and to send messages to individual device.
The device token does not change every startup.
It is created when the application is launched for the first time, and can be updated in special cases. When the token change (again, this is rare) the FirebaseInstanceIdService.onTokenRefresh() callback is called.
In a generic chat application you might want to:
first authenticate the user with your login system
upload to your server the mapping user-id > device-token
send messages to the users via the FCM server-side APIs.
Update to address one of the comments:
The server-side API allows to send the same message to multiple tokens in the same HTTP request. See registration_ids in https://firebase.google.com/docs/cloud-messaging/http-server-ref#downstream-http-messages-json
You should not use the server-side API in the client, because that would require you to add the API-KEY in the application which is a security issue (people could decompile the app and read the key)
The storage structure is up to you. For user-id > multiple-device-tokens a dictionary could work.
If the token are non reusable. So it's safe to send messages to expired token.
Token generation requires internet connectivity, so it could take some time.
To handle token after user registration see this question:
How to launch FCM ID Service only after a particular activity is triggered?
I'm planning introduce two factor authentication to my iPad application. Currently user login to my app using a username and password. That username and password is validate from the back end web server devloped using .Net. If user is authorize to login then he can access the iPad application.
Now I want to introduce two factor authentication to validate user. I want to know what are the options we have here. Since we have user’s phone no with us I was thinking of sending a passcode to his phone each time he tries to login to the iPad application. But iPad doesn’t support sending messages over the GSM/CDMA network. Is there a way to achieve this? (Thought about getting an SMS gateway from the local ISP and writing SMS a server. But it cost more) Third-party module will be ok.
Check google authenticator. https://code.google.com/p/google-authenticator/
I think it is quiet good for two-step authentication.
Here is source code for server side (it is on php but i think it is not big issue to convert it to .NET or another platform) https://github.com/chregu/GoogleAuthenticator.php
As I know it uses Time-based One-time Password Algorithm http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm
You can send an SMS to the mobile phone of the user with a code.
After that the user puts the code and the APP validates the code making a request to the server.
The SMS is sended after the user sucessful introduced the username/password.
Other option (less expansive) is to send that code by email.
You should try the google Authenticator
There are other's like https://www.gauthify.com, who offer this service.
You may be interested in looking in this StackOverflow Post.
I cannot fully express how much I am impressed by Twitter's recent TFA implementation, it is extremely convenient and (assuming they didn't botch the protocol) much more secure than many other forms of TFA.
Here's a description written by Wired.
But to summarize you activate a device for TFA and it generates a private (device)/ public (server) key pair. When you try to login after receiving correct username/password credentials the server sends a push notification to the application on any authorized devices encrypted with the public key and the application decrypts the nonce and sends the nonce back to the server and is given a session.
And of course as others have mentioned, there are prebuilt services you can use such as Google Authenticator, but they tend to be clunkier and there are concerns about SMS and TOTP security.
Two Factor Authentication means confirming something the user knows (their password) and something they have in their possession (like a physical key, a badge, or RSA key fob; the important part is it's a physical object other than what you are giving them access into). Sending a push of any kind to the iPad they are using to login to the app defeats the purpose and is no better than single factor (password only). Your only choices are:
Distribute an RSA key fob (or similar). Probably not an option because of the cost & management overhead associated.
Create an authenticator app that only works on a separate device than the iPad with your app on it (along the same lines as the Google Authenticator app). You can probably prevent the authenticator app being run on the iPad by registering a URI scheme for your protected app and trying to open it from the authenticator every time the authenticator is opened. If the protected app opens that means the user is trying to run both on the same device and the authenticator should not validate them.
Send a SMS to their registered phone with an authentication code. By using SMS here you're forcing the user to have both devices to be able to login, which is the key to TFA. Note that a creative user could register a Google Voice number (or similar VOIP with SMS app) on their iPad, thus circumventing the physical aspect of TFA.
I am using Amazon SNS Service for an iOS application that needs push notifications.
I have figured most of the things, except for the part where I have to register my device tokens.
This is where Amazon talks about it. It can be done manually or with the help of createPlatformEndpoint API which they obviously recommend for bulk uploads. My question is how we can directly register tokens from devices that will install the app later on. The documentation talks about a proxy server which I would want to avoid as of now. Isn't there a direct way of doing this, like where I can directly call a method and push the device token received in the application to my SNS Platform?
This, is a possible duplicate except that it is in reference to Android.
The AWS Mobile SDKs support accessing SNS directly from the mobile device. If you're interested in seeing code demonstrating this on iOS, we included some as a sample we prepared for re:Invent 2013 called Mobile Photo Share.
The important thing to note when accessing SNS directly from the mobile device is that you'll want to restrict the credentials delivered to the device to only those services and resources you'll need to access. You can accomplish this via web identity federation or a token vending machine with appropriately restricted policy.
If you want to learn more about the Mobile Photo Share app, we had two talks at re:Invent about the app and its architecture. The video and slides for those talks are available here:
Building Cloud-Backed Mobile Apps
Integrating Social Login Into Mobile Apps
Am trying to develop a coupon using Apple Passbook. My scenario is i have a web server from which i have to send the offers to iPhone as a Coupon. I tried to understand about the communication how happens between them, but not clear about it. Can anyone suggest me,
How can i send the offers from my web server to iPhone as passbook?
Where i have to store my data either in my database or anyway we have to store in iphone?
If user views a coupon sent by us, how the user can use the coupon?
How can i send the offers from my web server to iPhone as passbook?
The process is as follows:
Create a pass containing your webserviceURL and authenticationToken
Once the user adds the pass to Passbook, their device will register with your web service and provide you with a device id and device token.
Update your pass database with the new offer information
Send an empty push message to the device token (from step 2) using the certificate (passTypeIdentifier) from the pass
The device will receive the push and will contact your web service for a list of updated serials
Your web service returns the serial number(s) of the pass(es) that you wish to update
The device then request the updated pass(es)
Your web service sends the new pass(es)
See this document for details on the web service specification. Also note that your production web service must use https.
Where i have to store my data either in my database or anyway we have to store in iphone?
In your database. The iPhone will only hold the information necessary to display the pass (in the pass.json file). Your database will need to hold details such as the last updated time and the device id and device token. There is a sample database available as part of the ruby server example in Apple's Passbook Support Materials (Apple developer account required)
If user views a coupon sent by us, how the user can use the coupon?
That is entirely up to you - a passbook coupon is no different to a paper coupon. It is up to the pass issuer to decide how they wish to use it. In the most simple case, the issuer could scan the code, then send a request to update your database (with let's say 'status = redeemed'), your server then follows the steps above to push a new pass to the device showing the user that the pass has been redeemed.