I am locking my Mac screen with my Mac app. As I enters password it needs to unlock. The password should be generated internally. So I preffered to implement it by using "Two way factor authentication". By this my iPhone app generates a token frequently as I enters the token in Mac application it has to unlock.
I found few APIs like Gauthify and Authy. But they are generating tokens on their own apps(ie.,to get token from authy we need to install authy app in our mobile).
My requirement is without installing those apps,my app need to generate the token and communicate with my Mac.
Please guide me if any one had done it. Good suggestions are appreciable.
All these apps, including Google or any other apis use two step authentication. Here they generate a token with some private key and pass that to end user via sms or mail or any other medium. This sms or mail is registered with user in application database.
There is no need to use such app if you have your same app in your MAC and your ios Device.
You just need to identify how will you pass that key.
If MAC is generating token, and you know which device is trying to connect with MAC, you can send that token in background to that ios Device and match that. If you are using socket connections, this is option for you
When user enters Token, you can make a request to server to check that token. For this you need to send token genereated on MAC to server and save it somewhere. These tokens generally expires after some time, so run cron job to delete such tokens.
The apps you described use 2nd way to authenticate.
Hope this much help you. All depends your requirements and your approach :)
Cheers
Related
I'm dabbling with the MusicKit API and came across this in the sample app.
Keep in mind, you should not hardcode the value of the developer token in your application. This is so that if you need to generate a new developer token you are able to without having to submit a new version of your application to the App Store.
This makes me wonder where I should store the token since it has a maximum expiry of 6 months. Is the idea that I would regenerate the token on the server and have the app periodically request a new one? Am I missing something obvious?
I don't know MusicKit but I imagine you store the token in the keychain after requesting it from a server that you control. That way the app will work without an internet connection (after the first fetch of the token). Your app can ping your server when there's a connection and ask if there's a new token.
The other option is just to store it in the app's Documents directory if it doesn't need to be secure. The main difference is that they keychain data will survive a re-install. In either case it has to come from somewhere outside the app bundle (like your server).
I'm pretty newbie in iOS development but I'm trying to figure out how to organize the authentication. I need the authentication because of 2 reasons:
In-app purchases
User can add his or her own data into common database.
I supposed that as soon as user downloaded my app he or she will be easier to use the Apple id to authenticate but I have no idea if it's possible to use Apple id in this situation and how to organize this authentication on my server.
For information: I'm going to use Node.js as a backend with MongoDB, hosted on Windows Azure portal.
The workflow is:
User downloads and runs my app
User uses it (without any authentication so far)
If user wants to add his new data and share it the data should be
sent to the server and user must enter some credentials.
User enters Apple id credentials (and user name under he wants to
share data?) and sends his data to the server.
Further if he wants to do app-in purchase he uses the same
credentials.
If it's even possible? If I can't use Apple credentials to send data to my server, if it's possible to use other credentials (my email, or OAuth) to make app-in purchase? I don't like to idea to make user enter different credentials twice.
Thanks!
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.
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 looking for an API which will allow me to check whether MDM profile is installed on a device.
It won't be submitted to AppStore, so private API are fine with me. However, it should work on jailed phone (so jailbreak solutions aren't applicable).
Update 1
I am looking for a way to determine on iOS device whether this device is enrolled (vs checking from MDM server what devices are enrolled).
One solution that I can think of is installing the application through the MDM server (using the ChangeManagementState option to take control of an already install application). This will allow you to set managed app configuration options on the MDM server which the application can read from UserDefaults.
You can see how to do this here: https://developer.apple.com/business/documentation/MDM-Protocol-Reference.pdf#b3
If you need to verify that the correct MDM server is managing the device and not some random MDM server, you can create some type of signed document that is unique to the device (include the UDID) and signed by a private key unique to the server. The app can then verify this signature with the public key (probably shipped in the app binary since this seems to be a private thing) and determine if the app and device are managed.
The easiest option would probably be something like JSON Web Tokens. There are other options that exist as well: pkcs7, SMIME, CMS, etc.
For example, in the body of the JWT token, you could include the server domain, and the device UDID. This way the device can verify that this signed token is intended for this device and not simply being copied and reused from another legitimately managed device. You could also include a timestamp (and/or expiration) value to require that the token be reissued by the MDM server over some set time interval to ensure that it's recent.
{
"sub": "SOME-DEVICE-UDID",
"iat": 1516239022,
"iss": "mdm.example.com"
}
There are many ways to do this, I am just most familiar with JWT tokens. There are existing JWT libraries for Swift and Objective-C which could be used within your app to verify this token. Then you could be reasonably sure that the device is managed and managed by the intended server.