We are having an iOS web app for the iPhone 6s. This app needs user authentication in the context of licensing. The user should be able to authenticate himself and must not be able to give his own license to someone else.
Here are the ideas I was thinking of yet:
1: IMEI
If I could retrieve the IMEI using PHP or JavaScript, it would be a great start. But this is not possible, unless it's a native app. And that's just not an option here.
2: Authentication token
Passing a secret authentication token through the URL, like a serial key could work. But the user could easily give it to someone else. And checking IP addresses to detect unlicensed use is not easy, because IP addresses of mobile devices change and make it hard to distinguish one user having different IP addresses from multiple users.
I'm trying hard to think outside the box. But is there any way to authenticate the user of this iPhone web app securely?
We don't want security through obscurity solutions here; It may be not possible to make it definitely impossible to bypass. But it should be as secure as possible.
Related
Currently in the middle of a rather long-winded process of deciding upon the use of TouchID within an application being developed due, to security concerns, and wondered if anyone had any advice?
The idea from a product point of view is that a user can register with the application with a username/password (bog-standard flow in case of fall back for devices with no touch id) and then at a later date, if turned on via in-app preferences, use the TouchID system to 'login' to the application instead of typing a username/password again.
My concern is that this somehow means we have to store something on the device (retrievable upon successful touch) which can then authenticate the user and allow them access to the API (via JWT token, but probably doesn't matter).
This goes against almost everything I have ever read and been involved in with regards to mobile application development, which is storing anything sensitive on the client device is opening yourself up to an attack vector.
Yet - many applications already do this, so I am wondering what a typical process for enabling such a feature would be?
The app is sensitive by nature, has some personal information management which would be bad if leaked, if this makes a difference to the approach!
Thank you in advance
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 building a backend for ios apps, that support login in different networks.
Once the user login in to the network the client tells the news to the backend, and this could offer a list of worlds that the user might play, or even delete old worlds.
One way to steal another person's world is by saying that you are his social network id.
To solve that with facebook, we force the client to send us the fb_token, a token provided from facebook to the client, that we use in the backend to ask facebook if that specific user is the one that he told us to be.
If apple doesn't provide a way to validate this I understand that if an iOS app wants to use game center, it is directly forcing the app developer to also use iCloud because apple can validate the user credentials.
Did apple provide any way to validate user credentials?
The client on iOS can retrieve info about the currently logged in player in GameCenter, which has nothing to do with iCloud.
If you want to use iCloud to authenticate, you might have a different player than the one you wanted.
I think the solution is for the client to retrieve the player info in GameCenter, and send it to your server in an encrypted fashion (say HTTPS), including a timestamp and possibly other dynamic information. This way you'll know that the user info is being sent from the client app itself and there is no man-in-the-middle. That's really the issue that you are struggling with: how to ensure that client-server communication is secure.
I'm trying to work out the best architecture for a couple of apps I'm developing.
In both apps I want to utilise google/twitter/LinkedIn/etc to provide authentication of a users identity. The app is composed of an iOS app which has an option to send data to a server which I'm writing in node.js.
I want to utilise either OAuth or OpenId to handle identifying a user against the above servers so that I don't have to put in an authentication system of my own. In other words, allowing users to re-use their ids when choosing to upload data.
I should also note that apart from identifying a user, obtaining a name and email address, I have not intention of using any of their APIs at this time.
I think I have two options:
Place the Authorisation code in the iOS client and transmit some sort of key to the server with the data which it can then verify.
Keep the iOS client fairly dumb, and handle authorisation from the node server.
I'd probably prefer the second option because it means I could centralise authentication and be able to support a web site as well. That's my current theory.
Can anyone who has done something like this give me some pointers as to the pros and cons, OAuth or OpenId, or links to some examples?
In our previous app we opted for a combination of the two approaches. We wanted to centralize our user data on our server in the event we needed to make future API calls on those services. We also wanted the native oAuth experience for the user on the client. Ie: on Android and iOS, the developer can have single sign-on / authorization run through the native Facebook app (if available), vs. popping-up a webview that serves the 'Approve' dialog. It's a better user experience in my opinion. Also for Twitter, the oAuth process may require a PIN code to be entered in the callback which should probably be handled on the client side.
You can pass the access token retrieved by the client to the server for storage and later use if you intend on making additional API calls on these services, provided you expect the token to be long-lived (ie: offline-access permission on FB).
In any case this is mostly a user experience decision.
I am trying to develop my first PhoneGap application, using MVC.NET to serve the JSON to the application. I am though in doubt how I can secure the controllers on my MVC.NET application so only PhoneGap applications can post to my server.
I e.g. have a settings controller where the user can update his/her settings, but how would I make sure that no one tampers with it?
I had plans to use the deviceID as the userid, so the user doesn't have to create an account to login, but does this rule out the possibility to make it secure, since I don't Authenticate the user?
You need to use the same sort of authentication/authorization/security mechanisms that you would for any other web site. This means that authorization information shouldn't be passed in the clear (use SSL, encrypted cookies). You should choose authentication information that is difficult to guess or impersonate (user id/reasonable password; I'm guessing device id might be less secure if it's broadcast regularly). You could store this information on the phone, but with varying levels of security, i.e., if someone gets physical access to the phone it's likely that they would be able to access the credentials you store.
You might want to look at the security wiki for more detail/information: http://wiki.phonegap.com/w/page/43660891/Security