Encryption of credit card information on iOS application scenario - iphone

We want to encrypt credit card informations and save on our server. The encrypt/decrypt keys will be saved on the user's iPhone. But if the user reinstalls the app, we will have lost the keys and we will have no way to decode the card informations.
We want to find a way to save keys on any other safe places. Any suggestions on this issue?

Keychain data stays in place after an app gets deleted. You could eventually rely on this to store the keys (also, this is the most secure place where you can store them).
References:
How to find out WHEN a user bought the app / installed it for the first time (possible without UDID?)
https://forums.developer.apple.com/message/112814

Related

Password/Authentication for users inside App on iOS

my goal is to give my customers an option to lock their App's Data, so when they give their iPad/iPhone to someone else for an extended period of time, users can't access or accidentally look at confidential data.
[Some Background: It's a medical Application where physicians/staff-members would give iPads to patients. Now the patients are supposed to access some contents, yet shouldn't be able to look at other patients data]
So far, I have a password inside my App. But when a staff-member forgets and wants to reset it, the only thing I can do is "deletion of the whole database". I have a Disclaimer telling people to store their password somewhere, but this is still not the optimal user experience.
Is there anyway I could authenticate the user via his Apple-Password? This way only the person knowing the Devices-Account password can access the data and can always reset the Apple-Password with Apple.
PS: Server-Solutions, like having a User-Password pair with reset-via-mail on a server of mine is out of the question, since it would add to much complexity for the users and in many medical situations the Device shouldn't have access to the web.
Multiple thoughts:
I am not aware of any native public API to authentication using Apple password.
If your app is enterprise app, possibly you can use native private API. I would recommend to disassemble AppStore and check how does it do authentication then
You can also to try to access to some Apple web page which requires authentication and pass to it apple account and password and see what it will return. If it authenticated correctly, then you are fine and you can reset a password.
To make it secure, you will need to ask a user to enter it for a first time, so you can encrypt your encryption keys using authentication material (so you can decrypt encryption key later on).
However, I am not very big fan of this solution, since you can change Apple password and you will be stuck in such case.
Server solution is the best option and it's not that complex. Another option is Forgot password. You ask something what administrator know ("What is your first pet?") and he enters the answer when your application is configured and this answer could be used later to unlock your app.
P.S. And the best solution at the end (which is absolutely shameless self advertisement). A startup which I am part of (SpydrSafe) works on the product which solves exactly your problem. In fact, healthcare is one of the verticals which whom we actively works. If you are interested, contact me (my email is in profile)
if you authenticate the user via apple password, and they forget their apple password, then in order for them to retrieve that password is by reset-via-email .... so either way you are stuck with that dilemma.
As for actually using your apple password, no.
Best way to get what you want is to have the password stored somewhere in real life. Like another computer that the doctors can report to and ask for passwords or just don't forget the password.

Pressist CFUUIDRef After App Deleted

Recently apple has reject apps that uses the unique device identifier (UDID), in my app i am creating once aCFUUIDRef for each device on the first time, which works great.
in my app i am giving to a new user 10 clicks on a button (some service), when i am creating a device id for the first time it sends to the server and this id is now have credit of 10 clicks.
the problem is when the user delete my app it generate a new identifier.
how can i write some file to the iphone withe an identifier lets say for example "MyCustomDeviceID"
and when a user download the app i am checkin if this file is existing, if it does i am getting the saved parameter and if it doesn't i am creating the identifier and then creating the document.
i got to have some way to leave a mark on the iphone.
ideas will be appreciated!
Assuming that you can convert a CFUUIDRef into an NSString, you can store it in the keychain. Items stored in the keychain persist across app deletes. Check out PDKeychainBindingsController for reference.
On iOS you have no "shared space" where save data and maintain it after the application deletion. You have to do it in other ways:
you can enable iCloud for your app and save your id using NSUbiquitousKeyValueStore.
You can save your identifier in NSUserDefaults, so if the app is deleted and then reinstalled it will be available in the backup. (obviously the user have to restore from backup)
Or you can associate the identifier to a nominal account. (you have to create a system where the user can do a registration and login with this nominal account)

How to make inapp purchase using MKStoreKit 4.x receipt secure from being modified?

I have been storing inapp purchase receipt string in nsuserdefaults or a custom plist .This string used to determine the version of the app as full or limited.But how to make it secure.If any person modify this string by modifying the plist the app will change to full version rite.Then i came to know about keychains,but i am not able to understand how it works..is it a separate place where the string is saved or is it encrypting the string and saving it in plist..If anybody knows how to save inapp receipts from mkstorekit using keychains please share it here.. and also the keychains concept
The keychain is actually a safe, encrypted storage for passwords or anything else. You may use SFHFKeychainUtils. That makes using the keychain as simple as using NSUserDefaults.

How to safely store credentials entered in Application Preferences?

My iPhone App connects to a web service using a username and a password.
I prefer to save the credentials in the Application Preferences (settings bundle) like the Mail App. Is this secure enough? Is it possible to save those values to the keychain (via Application Preferences)?
Edit:
I want my users to enter their credentials in the Application Preferences of my App. Normally, I can retrieve this data in my app with NSUserDefaults. But Application Preferences saves the data as plain text and it's neither encrypted nor hashed. Is there a safe way? Eg. I know the keychain on the iPhone and I find it great! Can I use the keychain to hold the credentials entered in Application Preferences?
Food for thought: How does Apple do it? I mean, when I want to use the Mail App, I provide my username and password in the Application Preferences. Are those values stored as plaintext?
Did you check the keychain documentation? On the security, see this white paper by the Fraunhofer SIT institute.
Keychain Services will be required for secure storage. Using NSUserDefaults will not secure your data.
You can save it securely using Security.framework.
It is very nice sample from Apple where many aspects of using that framework are discussed. I advice you to look through it. Here is the link to that sample: GenericKeychain
This sample shows how to add, query for, remove, and update a keychain item of generic class type. Also demonstrates the use of shared keychain items. All classes exhibit very similar behavior so the included examples will scale to the other classes of Keychain Item: Internet Password, Certificate, Key, and Identity.
It seems that many people do not seem to understand your question. Unfortunately I can not find the answer myself. The question is how do you use the keychain AND NSUserDefaults at the same time.
I too would like to use the NSUserDefaults interface.
Hopefully we can figure this out...
One option would be to store just the username. Then when the app starts if there is no password in the keychain or if there is a wrong password in the keychain--ask for a new password.
You can remove items from NSUserDefaults when your app runs after the user uses Settings to enter them into the app's Application Preferences. Then put them into the keychain. But these items may be in plain text in storage in the interim(depending on which iPhone model, some may encrypt the flash storage and the backups), before you can remove them from NSUserDefaults.
Apple owns the entire OS and of course the Mail app. They are using features outside of the public SDK, because they can. How do you think the Mail app can run in the background and keep checking for your mails? Normal app can't achieve this :(
Back to your main question, using keychain is the right way to go. But you probably have to disallow users to enter username & password in Application Preferences. There is no way to secure that.

UUID is unique? iphone

Can i save an UUID in an external database in order to check if the user posts his message only one time from his iphone? I have searched and i have found that there is no way to save a NSString value after the app has been deleted. Am i right?
When an app is deleted, all of its data is deleted too. You could store the UUID on a remote server, however the iPhone's UUID will be the same regardless of how many times your app is deleted and reinstalled.
Note that this can be a security concern as your remote server may recognize a device which has been wiped and sold.
You can save an encrypted NSString in the keychain, and that string will survive the app being deleted. However the user can still securely wipe their phone to clear the keychain. Or log in from multiple iOS devices on their same iTunes account. Or exchange their device for another new device at an Apple store if there is some sort of warranty problem, etc.