This is a cross-post from my Programmers.StackExchange post - I think this might be a better forum to ask this question. Admins - please delete either of them as you deem fit.

On my mobile app, I am storing the username of a logged in person, and downloading some data for the given/stored username. When the user checks for updates to his data content on the server, the server dishes out a delta of the content, based on the username. The app then updates its local display accordingly.

The problem is, since I am using localStorage, there is no guarantee that someone will not edit the username stored locally and try to request data meant for someone else.

What would be the best way of getting around this possible security hole? Please comment on this method that I am planning to implement:

  1. Each time you login, a random string is generated and stored for future checking in a database, along with your username, and date/time of request.
  2. Whenever a request to download data for a username comes in, it must be accompanied by the string from the previous attempt. Also, each fresh update for the client is accompanied by a new random string, which is stored in the database and the old one is deemed expired.
  3. If the random string is not provided correctly, the user is logged out of the mobile app (as this could potentially be someone tampering with the app).

The advantage I see for this method is that I have an audit trail as well for later verification and forensics. What are the flaws and what could I do better?

  • Cross-posting is generally not allowed. Please pick which one you want to keep, and flag the other one to be closed by a moderator (you can click the "flag" button to ask a moderator to close it). I think IT Security is a better fit than Programmers, personally.
    – D.W.
    Commented Jan 9, 2013 at 10:57

1 Answer 1


You need to authenticate the user's mobile device (thus implicitly authenticating the suer).

I suggest that you generate a fresh, random 128-bit string (using a cryptographically secure PRNG), store that on the device, store it on a server-side database associated with the user, and use that to authenticate the device. The device can connect over SSL and then send this 128-bit string to authenticate itself to the server. If you are using HTTP, one very convenient way to do this is to put the 128-bit value in a secure, persistent cookie and use HTTPS. The 128-bit string can be stored on the device permanently. This way, the user never needs to log in again.

Alternatively, you could authenticate the device by having the device generate a fresh client cert, and then connect using SSL with this client cert.

  • Yup, makes sense - to make the string a one-time generated persistent one on the device, instead of regenerating it each time. I am already using HTTPS, btw! Commented Jan 9, 2013 at 16:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .