Verifying a user when backing up data to a server

Question

Note: Although I raise this issue in the context of an iOS app, I don't think it's confined to an app running on that specific OS.

I'm developing an iOS application that will back up user data to a server and I'm trying to figure out the best way to verify server-side that the user being updated is actually the real user. Each user will have an id (uid). If that's all I depended on server-side, then I imagine the process would go like this:

• User runs app for the first time
• Creates account in the app, which communicates with the server to both create the account on the server and to get a unique "user id" (uid)
• App stores this uid so that it can identify the user in subsequent communications with the server

However, if someone were to hack the app on their iphone, they could change the user id value and then that would instantly give them access to/allow them to modify a different user's data.

The current solution I'm considering is that the user receives 2 unique ids, the uid (just an auto-incremented number) and a longer, more complex key string. All communication with the server will therefore have to send along both the uid and the key. The server will verify that they match in order to make sure that the user truly is who the app says it is.

So, my question is two-fold:

1. Is this the correct way to achieve this? Or is there some other standard method that I should pursue?
2. If this is the correct approach, what's the recommended way to generate the unique key?

Answer 1

First of all, you can use the more complex value as the user ID to begin with, if you like (e.g. a UUID). Monotonically increasing IDs get hard to manage as your service scales.

You have the same problem a secure web site does when it leaves secure cookies on the browser to remember a session. Those cookies do include the user ID, but must prevent tampering. This is generally done by signing the cookie on the server before sending it back.

So what you'd do is:

1. Generate the user ID on the server, and use it to create some sort of "auth token" for the client to have to sign in.
2. Sign the auth token on the server with a secret key that only your server knows.
3. Send the auth token to the client, where it is stored for all subsequent logins. Transfer the auth token over HTTPS to prevent someone else from snooping it on the network.

When the app goes to login, send up the auth token to the server. If it's been hacked, the signature validation will fail, and you'll know to reject the client.

Consider including a timestamp in the signed token as well, so it expires after some time, forcing the server to regenerate an auth token periodically, which protects you in case your key is compromised. It's hard to do this all fully unless the user himself has a shared secret/password he can use to authenticate periodically as well. Depends on how far you need to go.

Other considerations: If all you know about a user is their generated UID, you don't have any way for that user to come back later from a different iOS device and restore their account there, right? Generally, if the user will be creating anything "valuable" in their account that they'll want access to later, you'll probably want to create a more traditional user account backed by an email address and password or the like, so they can access the account again after reinstalling your app. (This may or may not be relevant to your case.)

Answer 2

I would recommend going the "standard web browser way" and just letting the user set an email (login) and password.

When the iOS device connects to the server (using HTTPS), it uses regular "basic authentication" to log in, and receives a cookie which is valid for a set period of time. As long as the device keeps requesting data from the server within the cookie's lifetime, the cookie is renewed, and when the cookie is expired the server will automatically challenge the client to log in using its stored information again.

This has some advantages;

• The user can log back into his account with a new device with a regular password reset. Easy, straight forward solved problem.

• There is no special solution on the server side, any server side script can require authentication just like it would for a browser - built in functionality.

• You would not have to invent your own security scheme. This scheme is used by millions of browsers every day to authenticate to web sites.

• Not tied to a special phone, if the user has several iOS devices, he can use the same account from all of them by just logging in. No special set up procedures.

In other words; no special solutions for you to develop, generally solved problems how to handle login information, proven security and ease of use.

According to me, you can't really beat that :)