We are creating an app as follows:
User starts with 2 free "tokens"
User can buy a pack of 10 tokens with $.99 in-app purchase
We have implemented this using NSUserDefaults to save the number of tokens.
Is there a way to make our free 2 token setting persistent? Even if they delete the app? Right now you can delete the app and reinstall to get 2 tokens again. iOS 5 has NSUbiquitousKeyValueStore for saving settings to iCloud, is that any better?
If not we will have to use a web service for this...
NOTE: This app is in MonoTouch, but probably irrelevant to the question. Also, in our app, the user wouldn't care to reinstall the app to get 2 more tokens (there is no other settings or game progress they would lose).
Just my 2c as #Almo covers most of this already and should get the credits :-)
NSUbiquitousKeyValueStore has the advantage of being by-user, e.g. several devices would share the same free tokens. OTOH that might not be something you want in your app...
Leaving data after uninstallation goes against the sandboxing of applications. There are ways to do it, like you can add images/photos/contacts/..., but unlikely to be "Apple approved" and more than likely easy to hack around.
So I also suggest you to use a web service. A simple way would be to validate with the service (e.g. using the device's MAC address since the device unique identifier is going away) when no application data is found (install and re-install) if it's a know device (no token) or not (get tokens).
If the paid tokens are re-usable (could be re-played by re-installing a backup that includes them as data) then you might want to track them with the web service. Non-reusable tokens won't suffer from this (and are likely easier to deal with).
You can set token to the Keychain. If the user uninstall app and install it again you can restore token from the Keychain.
sskeychain
Even if you try to make the setting persistent, I don't think it would be that hard for them to find that and delete it as well during a reinstall. If you want to prevent just casual cheating, maybe that's fine. But if this is your revenue stream, I'd recommend using a webservice.
Edited to add: I don't have any experience with iCloud. That might make sense, too.
Related
Every application that generates dynamic content must have a server whose address is embedded inside the application to enable communication with server.
Now in the case of WhatsApp definitely they have also embed the server's address inside the WhatsApp application. For example someone reverse engineer the WhatsApp apk and found the address of the server, as well as he also found the parameters and all the stuff that the application sends to the server (i-e session, token, authentication key etc etc) for successful communication, so is that mean he can use these same parameters structure and the server address in different third party app to play/communicate with the WhatsApp server? Because server is just an electronic device that works on the digital signals and thats it. Server don't know that these parameters are coming from the authorized WhatsApp apk or from third party apk.
If yes, then don't you guys think that there should be solution to that problem?
If no, then what are the techniques and algorithms they are using to stop requests from unauthorized/fake apps.
I believe not any employee from WhatsApp will answer here to share the algorithm, but i know SOF is full of geeks, if someone knows how WhatsApp stops these kind of issues please share, otherwise i will be still glad to know about the advice and ideas that you guys have in your mind for the best security practices.
How banking, paypal etc and messaging apps including WhatsApp works in that scenario and how they stop the issue that i described above?
Important:
I am not going to reverse engineer the WhatsApp, i am just creating a server and fighting with this issue to be solved to secure my server and only accept request from my app but stop requests from unauthorized/fake apps.
Thanks & respect to all in advance who will contribute.
There is no way to prevent malicious reverse-engineering, resulting in a fake app pretending to be the real thing. While you are working on your server, you need to do defensive programming, that is, your server shouldn't assume that the request was sent via the app. So, if you protect your server against all kinds of malicious and deliberate misuses, then your server is safe.
However, that's easier said than done, because your project is developed by a finite amount of people and - if it becomes successful then - the audience contains a swarm of smart bad people.
You will therefore need to detect a subset of features that you need to absolutely protect against misuses and prioritize testing and improving those, by thinking with the mind of a fictional hacker, who would like to either gain unearned profits or do harm to your project. Schizophrenic, I know, but you need to do that on the server. You also need to improve the security of less than critical features, but at a lower priority and log the requests you get, so if SHTF, then you will have at least a chance to deduce what caused it and how.
If the phone app is in your hands as well, then you might implement some additional authentication for each version, like generating a version token for each user that downloads your app. Since the version token generator algorithm would not be in the hands of hackers, they would have to solve that on a per user basis, which is extremely laborius to solve this for several users if done by hand and if they work it out in a way to make it automatic, their solution would be viable only for a version.
So, there is no 100% accuracy in this area, but you can make life very hard and miserable for people payed to hack through your application.
I'm submitting my first app through iTunes Connect. It is a social networking community so I have to provide a demo account for the submission. My app already has a live database of users as there is currently an active web version.
I'm new to this and confused as to how I should handle this. Should I be creating a demo account that will not show up in any other live user's search results? Are the testers going to be attempting to interact with other live users? I am assuming I will need to show the various functions of the app, like messaging and events. In that case should I be creating a few "demo" users for the testers to interact with?
Alternatively, should I be linking them to the development version and development database? If that's the case, then the build that I send them would only be a development build then?
I am confused on how this is supposed to work and can't seem to find any information to help?
In my experience, you'll need to give them the production version that will go into the store. So not the development build.
When we submit an app for approval, it seems to get installed and activated on a couple of devices, but nothing much ever happens. They barely use it, as far as we can tell. We can tell that it's installed and run. We have previously been rejected when the network connectivity wasn't working right, so we know that they do look at the app after it's installed.
I'd suggest you make them an account that looks relatively anonymous (or even "Test Account" which you real users are hardly likely to try to interact with). You could create another account and say "If you want to send a message, send it to account xxxx". We've never had them interact with our app enough to utilise the suggestions we've made.
If you have an active / inactive flag, you could think about making these accounts inactive once the app is approved, then re-activating it when you next want to submit your app.
I'm brand new to OS X and mac programming. I'm looking to write an app that runs continuously or is woken up every 30 seconds to do some minor task. It would do something like check the weather via a web service and shoot off an email if the temperature drops below freezing. In Windows I would just use a service or put a repeating task in the task scheduler. Is there a standard way to accomplish this in OS X which the mac app store allows? I would like to write something that I can put in the store but Apple seems to have vague restrictions against running background processes.
I've learned a little about launchd but I can't tell if I am allowed to use it. Ideally the process would get run even when no one is logged in, but it probably won't need root access. If someone does happen to be logged in, it would trigger some popup if it sent an email temperature alert out. I would also have some GUI which the user would be able to modify the configuration files that determine the behavior of the background process. I don't anticipate any app store restriction for that piece of the project though.
I'm pretty sure an app that runs invisibly like that would not be allowed into the App Store. What you're going to want is to create a menubar-only application, which can be enabled by setting a key in your app's info, namely LSUIElement. Although it won't be able to be run unless a user is signed in, it's your only way to get it into the store successfully.
The MAS guidelines have several prohibitions that would impact you. Go to the guidelines and read section 2. In particularly consider 2.15, 2.23, and 2.27. I don't know any way to get your application running prior to login without at some point requesting admin privileges (even if you don't use the privilege when you run).
I would probably make it a Login Item (System Preferences>Users>Login Items), probably as an LSUIElement app as sudo rm -rf suggests. Definitely if it's your first app, I wouldn't go diving into launchd in any case. It is one of the most infuriating system processes I've ever dealt with.
After significant voodoo, I have finally got the scores API working. Turns out you have to set Enhanced Auth Dialog to disabled or Facebook ignores your publish_actions permission. Just a heads up in case anyone else is struggling.
However, I'm working entirely in the Javascript API. No server-side scripting is available.
The only way to publish a score is with an app access token. The only way to get one of them is to use the app secret, and that would have to be in the javascript code for the world to see. How bad is that exactly?
TBH I don't care if someone spoofs the scores to my little pong-style games. Good for them, only them and their friends can see it. It's just a bit of fun. But what exactly can go wrong if my app secret is published? Can someone hijack the entire application? Or is it just bad practice and nothing much can go wrong with a little mini game?
It's all purely javascript SDK so it seems to work only by user access tokens, so my first instinct is it's OK. But I thought I'd ask....!
What other permissions are you using? If you're using "publish_stream" I'm sure you could imagine the shenanigans that could ensue! Even worse, if the user has both your public and private key (which they will) they could create an entire spoof application that identifies itself as you!
The "domain" options in facebook should prevent this, but if there's any chance an attacker could do an XSS attack they could potentially write malicious apps that masquerade as your game.
Have you considered writing something very simple with google app engine for the sole purpose of dealing with the app authentication token?
I'm thinking about making a time limited full version of my App, so users can try it for example 7 days.
Is there a recommended Obj-C library?
First of all do not store your data inside the app. Otherwise it would be simple to delete the App from the filesystem and download it again restarting the countdown. Store it in User preferences or Application Support instead. You could use a plist for this. You could also use a hidden file if you like. Just don't make it too complicated or too invasive. Your app can be cracked no matter what security measures you use in the end. Just be fair enough to the end user that could be a prospective customer.
Here is a very nice link on the topic of implementing a time-limited trial in Cocoa:
http://lipidity.com/apple/shareware-licensing-techniques/
Without possibility to protect your data from manipulation/deletion it is not possible to do.
How do yo check, if it is first start of your application, if all your data is wiped out.
Some alternative is "hardcoded" id token and connection to the rest of world (at least for first start, to grab any kind signed data key)
Maybe you could use a server where store UUID's and first time they launched the App. Then, Each time they open your application, it asks your server if they can use it or not. It's harder than store dates on device but if you do that, users will access your application simply changing the date of the device on Settings.