I have a game I originally wrote for PC that I'm now porting to ios.
It is an online multiplayer game that requires the user to have an account with us. To do this they sign up and register right in the game.
We want to try to prevent the same user creating lots of accounts. If it happens it's not critical, but we want to diminish it.
On PC we store a file in app data saying an account has been created with this computer. so it is hard for the average user to circumvent that.
Unfortunately on ios, there does not seem to be a way to permanently store something to prevent the user from creating multiple accounts. They can uninstall and reinstall the app, clear keychain data, etc.
What is / are some ways that can be used help prevent multiple account creation?
Thanks
Actually keychain items are not cleared on app uninstall. You can store their playerId there. And you can fetch that the next time user installs the app.
There is no sure shot way using which you can prevent users from creating multiple accounts. At most you can make it difficult for an average user to do so.
Related
Working for a company where we are starting to have many small apps, each with their own log in screen.
So that means whenever someone's password changes, they'll have to re enter their password for every app
Can be cumbersome to the user, especially when our policy is to have user's passwords change every 3 months and there are 6 or more apps to enter the password on
Has anyone come up with a work around for this problem where the user would only have to enter their password once? I'm thinking I could have one dedicated app solely for authenticating and then do some kind of interprocess communication if that's even possible
Again, doing this for iOS. I know on Android it wouldn't be an issue because developers can add accounts in the settings screen. However, iOS is a different beast
*Note these are enterprise, in house only apps. Not public facing on the app store
You need to store the username/pwd on keychain and share them between apps as mentioned here
https://developer.apple.com/documentation/security/keychain_services/keychain_items/sharing_access_to_keychain_items_among_a_collection_of_apps
In an iOS application, When I detect a users improper action (for example posting violent content), I wan't to suspend the user from using my application. The basic idea to implement this feature is to create and save an unique id for each application installs and suspend the usage from server api's.
My question is, how can I implement this feature even if the user re-installs the application, and still pass the Apple's iTunes submission?
I came up with two ways to technically implement this feature, but wondering how Apple would respond.
Store the IDFA (I understand that users can reset the id on their behalf)
Store an app generated udid to the Keychain (which should not be deleted even if the user deletes the app)
I know there are no perfect answers, but would appreciate to discuss this issue with anyone that have tried submitting a similar application, or anyone that is well aware of the Apple's guidelines. Thank you.
Apple will reject apps that inappropriately use the IDFA.
If your app does not use server login (at which point, whatever flags you require could be delivered to the client), keychain storage would be the only real solution.
However, if you don't use server login, you block the device, not the user. Is this your intent?
BTW, without server login, a determined user can still get around keychain storage: Reset keychain on the device
You can block a given account. Most people these days key an account with an email address. Some require a credit card (Facebook fully validates accounts using credit card numbers), others require a bank account (PayPal has to send money somewhere!) and it is growing in popularity to request a phone number (Twitter is getting there). In the end, to really be effective, you have to block something that is difficult to produce.
With email, your users can always create a new account. Check out mailinator.com. Alternatively, all you need is one domain to have as many email addresses as you want -- I use five different email accounts daily, and I use about two dozen more on a monthly basis.
Installation ids are ok but users can always just uninstall/reinstall. And if you do manage to get a device-identifying number (easy to do really, even in the post-UDID era) so that you can block a given device, your users can just get a new device, or hack your app to use some random value, or spoof your API with cURL. I own three iPhones, two iPads, two Samsung tabs, three other Android phones, two Mac Book Pros, a mini, two PCs, and I run three virtual Linux boxes, and one virtual XP box. And what happens when somebody sells a blocked device to a non-abusive user?
So just block the user's account, keep excellent log files, and keep fighting the good fight.
I am implementing the feature of automatically logging in the user in an iOS app. This is easy for a single app as we can persist the username with NSUserDefaults while the password using System Keychain.
Now, I want to do it across multiple apps. In my understanding, we'd need a unique device identifier for this, which we can pass to the server and then use it to activate auto login across multiple apps on the same device. Now since, Apple prohibits the use of UDID now, I am thinking of using the Vendor Identifier which would of course require me to set the Bundle IDs accordingly. Is this the best way possible? Or is there a better standard method that is more effective?
Also, Is it at all possible to have auto login between different devices? Like for e.g. If I login on one iOS device and then open the app in another, I should automatically sign in.
To implement login between multiple iOS apps you can use the same App ID prefix in them. It will work because they will share keychain data. Here you can find more details:
https://developer.apple.com/library/ios/technotes/tn2311/_index.html
And here the related question: Keychain group access to share data between my existing applications
And about automatic sign in between different devices. I used encrypted iCloud Key Value storage to store login & password between devices. And it worked but not too good. Problem is that first time you start app on new device it will take some time to sync data from iCloud to local storage. And this means that first time you trying to Sign In and may need to wait for some undefined time. In may case it was about 20 seconds. To long for Sign In in a good application :) And of course this require user to be logged in iCloud with the same Apple ID.
ASAIK there is no proper way to implement automatic Sign In from multiple devices. And Apple recommend just to ask for Sign In on every new device of user.
To contextualize the question, our use case is an app through which users can get free promotional items on signup. We would like to prevent abuse of the system by limiting to one promotion per device. Since we can't access the UDID, we need some other (mostly) reliable way to check if the phone has already signed up an account. We don't need a solution that is impossible to circumvent, just one that is highly inconvenient to circumvent.
If we store a unique key in the user's keychain, then we'll be able to read it again even if they uninstall and reinstall the app. We're considering using this method to track devices that have already signed up accounts.
Questions:
Is there a relatively easy way that the user could delete or change our app's keychain data? You can assume that the user's device is not jailbroken, and that they will not go to the trouble of completely reinstalling the OS.
What are other options besides using the keychain we might consider? Keep in mind that the app communicates with our server during signup, so we can store previous signup information of any kind on the server.
Are there any gotchas or problems with the keychain method we should know about?
I want to create a social networking ios app which costs money, and when the user buys it they are allowed to create only one account on the app. So the purchase is associated with the account somehow... or the app has a specific id on each device its bought on... would I need to use gamecenter somehow...
How would I approach something like this?
Any help would be greatly appreciated.
First of all, more than one person may use the device (think a family with an iPad) so what your doing is inherently a bad idea.
That said, you can use an in-app purchase to let them buy account access - check with the server first to make sure a desired username is available, then let them use an in-app purchase to buy access, and on your server tie that purchase ID to the user name. Even if they deleted the app and tried to re-purchase (while logged into the same iTunes store account) it would see a purchase had been made and essentially be the same user. It even does kind of work with multiple users as they could switch iTunes accounts (though that is a pain).
I would also suggest trying to tie it to the users iCloud account in some way, which is easier for users to switch between on an device (a family might use one iTunes account but have separate iCloud accounts).
If you don't want to give Apple 30% of the registration fee, your only option is to have users sign up on the web and pay there, then have a login they can use in your app. Then it's a matter of trying to prevent duplicate logins on you server, although as a last point of thought, I can't remember a business that succeeded by refusing people's money.
You could generate an unique id on the phone, store it in the keychain, and use that to communicate with the server.
Since you are creating your own account management system, just save the user information once they do the account creation bit and never show the option again. Because developers no longer have access to the device id, you may have problems identifying an existing user if they delete and re-install the app, but I am not sure that there is a solution to that problem.
Edit: As a commenter to this question mentioned, you can save things to the keychain. Check out this link for a good lib for modifying the keychain.