2

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?

Improve this question
8
  • Instead of generating a random string just generate a MD5 hash of the username and the current date-time and transmit that to the server. Obviously it would still be vulnerable to mitm attacks.
    – Octavian Helm
    Jan 9, 2013 at 9:52
  • And then, on the server, how do I know if the MD5 hash I received actually contains the username?
    – Sudipta Chatterjee
    Jan 9, 2013 at 10:16
  • 1
    The MD5 hash can easily be created by a malicious client. A better approach would be to create a unique value on the server, combined with a timestamp and user details on the server and encrypt that with a key known only to the server prior to sending to the client.
    – Thomas James
    Jan 9, 2013 at 10:17
  • Yes so you are basically adding to my random string idea, to add the timestamp. However, I would not like to keep a magic key on the server. If the server is compromised (and although I have bigger things to worry about in that case), the key would be one more thing to worry about that it should not introduce new vulnerabilities. Instead, a simple MD5 hash of the (username +some user detail +timestamp + random string) seems like a good idea to push down the pipe to the client, along with storing the string and the hash on the server.
    – Sudipta Chatterjee
    Jan 9, 2013 at 10:20
  • Also beware with number 3, you'll need to consider network issues that may cause a client to be logged out if they don't receive the next string in the sequence as well.
    – Thomas James
    Jan 9, 2013 at 10:44

1 Answer 1

Reset to default
2

I suppose you need some sort of session which does not expire fast (say lasts a couple of weeks). In most mobile apps I have used you have to "create account" and login at the first time (maybe imitating their web counterparts) and then an occasional log in after some time or after a firmware update erases local storage.

Alternatively you can have the user provide to you a public key keeping the private. You can then encrypt the data with the public and the mobile phone will have to decrypt them using the local stored private key (which would bring the issue of how you persist the private key from firmware update erases). I would also consider a hybrid (public key from password): http://www.rsa.com/rsalabs/node.asp?id=2127

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.