We're developing an HTTP API for an iPad app, and we're thinking of only allowing the API to be accessed via an HTTP request that came from an iPad.
I'm not thinking of something like the User-Agent, because that can easily be forged, but more like some kind of authentication scheme that ties in with the App Store? Maybe the App Store signs each app with some kind of private key, and then you could insert that signature as a query parameter or header in the request and check on the server side whether the signature is from a legit iPad.
Is something like this possible or even a good idea?
If you control both the iPad app and the server app, you should be able to use PKI to validate that a request came from a legitimate app. Embed the public key in the app itself, use it to encrypt a value you put in a header field, and then use the private key on the server to decrypt and validate the received header value.
Related
I have just simple question. I'm using goole map and direction API. So I need to create API key thats fine, I have done it.
But When I edit my API key and select Application restrictions to iOS Apps and save it.
I'm using this key in my app then I'm getting below error message.
This IP, site or mobile application is not authorized to use this API key. Request received from IP address XXX.XXX.XX.XXX, with empty referer
But If I remove the application bundle id from iOS Apps then API key is working
Also I'm referring this question This IP, site or mobile application is not authorized to use this API key
But some confusion are, Can we keep it as blank? There is any security related issue? do I need to do any changes when I'm going to upload app on app store ?
NOTE: I'm using API key in all the places in the coding. like
GMSServices.provideAPIKey(googleAPIKey)
and
let urlString = "https://maps.googleapis.com/maps/api/directions/json?origin=\(myCoordinateStr)&destination=\(destinationCoorinateStr)&key=\(googleAPIKey)&sensor=true"
I'm creating my own Passbook Web Service, in order to register and update passes created by my server. When I add to the Pass information inside the pass.json the webServiceURL and the authenticationToken attributes, the pass is displayed but not added to the iOS Passbook App. Given I'm still in development I don't have a https with SSL server, but a plain http one:
http://192.168.1.100:8080/PassbookDelivery
Does the device and/or the protocol inside the Web Service need some special change in order to accept the pass produced by my server? Does the authenticationToken have any restriction, like string length, cipher or content?
NOTE: I already use the format URL for registering the device for updates, as detailed in the Passbook web service specification, which is (POST)
http://192.168.1.100:8080/PassbookDelivery/v1/devices/_deviceLibraryIdentifier_/registrations/_passTypeIdentifier_/_serialNumber_
but it doesn't get any call from the device.
Try this: go to Settings > Developer, scroll down to PASSKIT TESTING and toggle "Allow HTTP Services".
I'm curious if there is a way to safely pass content between apps on iOS. The ultimate goal is to implement oauth between two ios apps.
Since apps are not guaranteed to have unique url schemes, this option is out.
I have considered using keychain groups, but do not have experience with this. It looks like an app needs to specify exactly which apps can access the keychain items.
Are there any other options? Is there some sort of identifier (such as android bundle ID) that can be used to verify the apps during a request?
You can use URL schemes for this.
The basic process
You'll have a ServerApp and many ClientApps. The ServerApp listens to an URL-scheme like serverapp://. The client then can make a call to the server to ask it for authentication. The client has to implement an URL-scheme too. E.g. ClientAppOne implements the URL scheme clientapp1://. The server takes as parameter a backlink to the client app. E.g. the client calls the URL serverapp://auth?back=clientapp1%3A%2F%2Fserverapp-auth (here the backlink is clientapp1://serverapp-auth and has been urlencoded).
The server then checks the users identity, asks him for permission, password, etc. and then uses the backlink to provide the data. How the backlink works exactly is application specific, but you usually need at least 2 parts: an access token and a username. E.g. a backlink will then be clientapp1://serverapp-auth?success=1&token=fi83ia8wfzi3s8fi8s3f8si8sf&user=robert or maybe in case of error clientapp1://serverapp-auth?success=0&errno=421. The client then needs to verify the accesstoken through some public (or private) API, e.g. https://serverapp.example.com/userdetails?apikey=fai83jw93fj93389j&token=fi83ia8wfzi3s8fi8s3f8si8sf. The server will return some structured response.
Necessary components
an URL scheme on the server App
an URL scheme on each client App
an SDK that is to be included into each client app and that handels the details of authentication, and a standard UI component (e.g. facebook has a standard button that says "login with facebook", so the ServerApp needs some re-recognizable button that says something like "login with ServerApp")
a server that provides services that can be accessed through the access token.
a defined API that explains how the client has to communicate with the server
an SDK to be included into the client that handels such client-server-communication (should be part of the SDK mentioned in component 3.)
maybe a wiki that documents all of the steps above, so that you and other developers dont lose track
a way to invalidate access tokens, and a way for the client to detect if an access token has been invalidated. furthermore, if the user changes his password, all access tokens should be invalidated.
Random notes
in your client app you can check if the serverapp is installed by calling [[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:#"serverapp://auth"]].
the URL schemes should be sufficently collission-free. These URLs are never seen by users, only by developers, so they don't have to be beautiful. You can e.g. append the iTunes-Connect-App-ID to your URL-scheme, like serverapp1234567://. This will greatly reduce the possibility that someday some other app will use the same URL scheme.
I know this can sound absolutely stupid, but I could not find any way to solve this problem.
Say I've a mobile app: from this app, after purchasing an item, since the item is downloadable from a server, I make the user download a file to his device. Problem is it looks like it is very easy even for not so smart people, to get the URL of the file, so, without purchasing anything, the not-so-smart-guy can eventually download the same file for free (using a common browser).
Apart from the language I use (it is not important here, it can be JavaScript, Java, Objective-C, whatever), how can I prevent this issue WITHOUT developing an authentication system?
Generate a token for successful purchase, store it in the server side session or database. Add the token as a query string parameter for the file download request. Implement an filter for the file download request to validate the token.
To make sure that the URL is not share able - find some unique attribute of the device that can't be spoofed easily, hash(url,token,unique property) and add it to the url.
I am creating a Twitter client for Mac OS X and I have a Consumer secret. It's to my understanding I should not share this secret key. The problem is that when I put it as a string literal into my application and use it, like this:
#define QQTwitterConsumerSecret #"MYSECRETYOUMAYNOTKNOW"
[[QQTwitterEngine alloc] initWithConsumerKey:QQTwitterConsumerKey consumerSecret:QQTwitterConsumerSecret];
It is in the data section of my application's binary. Hackers can read this, disassemble the application, etcetera.
Is there any safe way of storing the Consumer secret? Should I encrypt it?
There is no real perfect solution. No matter what you do, someone dedicated to it will be able to steal it.
Even Twitter for iPhone/iPad/Android/mac/etc. has a secret key in there, they've likely just obscured it somehow.
For example, you could break it up into different files or strings, etc.
Note: Using a hex editor you can read ascii strings in a binary, which is the easiest way. By breaking it up into different pieces or using function calls to create the secret key usually works to make that process more difficult.
You could just base64-encode it to obfuscate it. Or, better idea, generate the key instead of just storing it - write something like this:
char key[100];
++key[0]; ... ; ++key[0]; // increment as many times as necessary to get the ascii code of the first character
// ... and so on, you get the idea.
However, a really good hacker will find it no matter what; the only way to really protect it from others' eyes is using a secure hash function, but then you won't be able to retrieve it, too :)
You should not use a secret api key in an application that does not run solely on your server.
Even if it's perfectly hidden.. you can always snoop on the data going through the wire. And since it's your device you could even tamper with SSL (man in the middle with a certificate created by a custom CA which was added to the device's trusted CA list). Or you could hook into the SSL library to intercept the data before actually being encrypted.
A really late answer...
If you setup your own server, you can use it for helping you desktop app getting authorized by users on twitter without sharing (i.e.: embedding) your secret key.
You can use this approach:
When a user installs you desktop app she must register it with twitter and with your server
*)
*) The app asks the server to generate the token request URL
*) The server sends the generated URL to the app
*) The app directs the user to the authorize URL
*) The user authorizes your app on twitter and pastes the generated PIN into it
*) Using the PIN you app grabs the token
*) All further communication uses the token and does not involve your server
Note: the app logs to your server using the user credentials (e.g.: id and password) for your server.