1

In response to this question: What is the most appropriate way to store user settings in Android application, if I stored an authentication token in the shared preferences, using private settings, how should the server handle this token? That is,

(1) How long should the token be valid?

(2) How can I ensure that another device is not attempting to use this token?

Community
  • 1
  • 1
user1876508
  • 12,864
  • 21
  • 68
  • 105

1 Answers1

5

(1) How long should the token be valid?

It will probably depend on what kind functionality are you implementing. Some apps use an one-time token each time, another ones are activity-based (for instance, if you don't use it within a time, it expires), others just don't expire it ever unless someone does manually (this would be Twitter's case). It probably will depend on how sensitive is your information, evidently if you're managing bank/money transfers, security should be a priority to you and probably a shorter period of validity would help.

(2) How can I ensure that another device is not attempting to use this token?

This would also probably be dependent on your own server implementation, i.e., the way you choose it to be implemented. Keep in mind that a token is a random string that is generated by the remote server and you need to keep some kind of database to store the mapping of emitted tokens to authenticated users. When you want to expire a token, you simply remove it from the database and this way you'll keep your database up to date and at the same time you'll also make sure that old tokens are not used anymore. That token will be ok (as far as security goes) as long as an attacker can't create a valid token, which is a token that has been emmited, is stored in your database and is current (i.e., non-expired).

Usually, a token that is at least 16 bytes long and has been generated with a robust cryptographic system (java.security.SecureRandom, /dev/urandom, etc) is considered secure enough to be used as a authentication system.

In order to avoid other users forgering tokens from other users, this auth tokens are usually generated this way:

  1. Generate a secret key in the server side (let's call it S) being it a sequence of at least 128 bits generated by a robust cryptographic system (java.security.SecureRandom, /dev/urandom, etc).
  2. The token should contain the time it was issued (T), the user name (N) and an integrity check (somewhat a checksum) calculated over N and T, and keyed with S.
  3. As the server is the only one that knows S, it can verify a the requested token and determine if it's true or forgered (as it's also based in the username).

I think those links could help you:

Community
  • 1
  • 1
nKn
  • 13,691
  • 9
  • 45
  • 62
  • When requesting the server for a generated token, is there any information which should be sent over, like a UUID or MAC address? This application requires a level of security similar to Twitter, nothing to the extreme of banking. – user1876508 Apr 21 '14 at 16:20
  • 1
    Once the server has issued a token for a specific client, it's the *client side* who has to present that token to the server and ask the server to do some action. If you simply want to use that server to issue tokens and check if tokens are still valid (i.e., it's not the server who does actions), simply prior to the actions that require authentication, send a request to the server presenting user's current token. if the server answers `OK`, let the user do that action, otherwise possibly redirect them to the authentication screen telling them that their session has expired. – nKn Apr 21 '14 at 17:46