Let's say I have an iPhone app that communicates with a database on a server through a PHP API, and I have problems with saving something like the user id in $_SESSION (you know, this can be painful sometimes), so alternatively, I can store it in NSUserDefaults or iPhone keychain, and send it to the server when needed, is it wrong/not safe to do such things on the app side rather than the server side?
Asked
Active
Viewed 168 times
2
Community
- 1
- 1
Abdelrahman Eid
- 881
- 2
- 13
- 28
-
1Can you lay out your specific use case more clearly. Really the way in which you intend to you some data the is stored in the client will determine what sort of security requirements you should consider. For example, if you want to want to store that user id in the client to uniquely identify the end client and potentially provide access privileges based on this value, then I would think that having that data stored in the client without any additional security mechanisms in place (i.e. login, use of some sort of access token, etc.) would be extremely problematic. – Mike Brant Feb 19 '14 at 01:18
-
Ah, I got it, to explain, I will tell you more about my specific case: When the user registers and logs in, he will be given an id for his username, *email, etc* according to the database, this id will be stored in the iPhone keychain *(for security)*. When the user attempts to post something an id will be needed, to identify who is posting, this will be called from the iPhone keychain going to the server. All this is as an alternative for saving the id in `$_SESSION`, because I have been running into a problem regarding that for 3 days so far. – Abdelrahman Eid Feb 19 '14 at 01:28
-
Using session wouldn't likely be viable here anyways, if you need to persist this data over longer periods of time. – Mike Brant Feb 19 '14 at 01:43
-
Why not viable? A `$_SESSION` variable is created whenever a user logs in, and that's what is required, now there will be no actual differences between saving it locally or on the server but the place the id is stored at *(it seems that I just answered my own question, lol)*. For reference see this: http://stackoverflow.com/questions/21868551/session-variables-doesnt-get-saved-when-automatically-logged-in – Abdelrahman Eid Feb 19 '14 at 01:48
-
Unless I mis-understand your needs here, it sounds like you want to create a persisted login state. Typically session data is purged after some (comfigurable) period of time (typically on the order of tens of minutes or perhaps hours), if you wanted someone to have the user id on their device and be able to come back to it a month later and post without "logging in " again, you would need to have a session timeouts that was months in length. Now if you have only a small number of users, maybe this is manageable, but it will not scale. – Mike Brant Feb 19 '14 at 01:52
-
No, actually you misunderstood that, and it is all my bad I am just bad at explaining things, I will try to do my best now. I don't want to create a persisted login state or something, I just want to create a pretty normal login state which is limited with normal period of time and the user has the ability to log out and re-log anytime. I just had problems with saving the user id to `$_SESSION` so, I looked for saving it locally as an alternative, which will also be for normal use *(I am not using it with the need for a persisted login state)*. Tell me if its clear or not, please. – Abdelrahman Eid Feb 19 '14 at 02:04
-
Try the answer from gazreese http://stackoverflow.com/questions/4597763/persisting-cookies-in-an-ios-application – EmilyJ Feb 19 '14 at 02:43
1 Answers
0
As per this thread regarding NSUserDefaults: On a normal device you can't really get at it, but if it's jailbroken the plist file is easy to read and change, it is not encrypted in anyway, so it's probably not safe for usernames, passwords or any personal information unless when you save it, you do some sort of encryption hash and then save that.
On the other hand you can try iOS Keychain or the iCloud Keychain. It says here that:
It's pretty secure, since any new device attempting to read your iCloud Keychain requires one of the following:
One of your existing devices verifies the connection through a push notification with manual acceptance.
When you enable iCloud Keychain on an additional device, your other devices that use iCloud Keychain receive a notification requesting approval for the additional device. After you approve the additional device, your iCloud Keychain automatically begins updating on that device.
Your iCloud Security Code
When you set up iCloud Keychain, you're asked to create an iCloud Security Code. It can be a 4-digit code similar to the passcode lock for your device, or you can have a more complex code automatically generated for you. The iCloud Security Code is used to authorize additional devices to use your iCloud Keychain. It's also used to verify your identify so that you can perform other iCloud Keychain actions, such as recovering your iCloud Keychain if you lose all your devices.
Entering the code incorrectly multiple times causes manual verification method
SMS verification to your phone.
The device that is using the SMS-capable phone number you provided when you first set up iCloud Keychain. A verification code is sent via SMS to this phone number. If you don't have access to this number, contact Apple Support, who can verify your identity so that you can complete setup on your new device.
Furthermore, you can also protect your iCloud account / Apple ID by enabling two factor authentication so that in many cases - the first use of your iCloud password on a new device triggers a push notification warning in addition to the automatic email that Apple sends when your password is used on a new device.
In summary:
- You get email notification when your password is used on a new device for iCloud - no opt-in steps needed.
- Keychain syncing has enhanced protection / two factor authentication baked in, again no opt-in is needed.
- You can opt-in to AppleID two factor authentication to further protect against password loss/skimming.
-
2But I guess using the normal iOS Keychain is much easier, and still secure too, right? Also, using iCloud Keychain can cause problems, like if a family is using one iCloud account, and two persons *or more* are using the app and one tries to post something, it may post on the behalf of the other *depending on who registered first* because he used his user id which identifies who is posting. – Abdelrahman Eid Feb 19 '14 at 01:37
-