This question talks about the session time out for web applications. I have noticed that most mobile phone apps I use never ask me to login again after the first login.

These mobile apps call web services to get the functionality done. So they must be using some token based authorization system.

It seems to me that, because the session/token never expires, if someone else gets access to the token/session they would be able to impersonate the user whose token they stole.

My questions are, a) Are above assumptions correct? b) How do mobile phone apps not log you out after some period of time and still achieve good security?

  • I'd debate that they always achieved good security. Some do, but others are dreadful - if an handles financial information, and doesn't use certificate pinning, for example, it can end up being MitMed and providing those details to an attacker. – Matthew Jun 10 '16 at 16:27
  • The main attack vector would be compromise of the phone itself. I guess they operate under the assumption that most devices are protected via a lock, and most stolen or lost phones are likely to be factory reset rather than having data extracted from them. If you're concerned about the data then you would encrypt your device. – SilverlightFox Jun 13 '16 at 11:00

They may or may not be using token based authorization, and they may or may not be timing out sessions. The reason they never ask you to log in again is entirely separate, and for convenience. Users don't want to log in over and over again, and apps that make them cause them to be unhappy, and being unhappy causes them to give the apps bad ratings, and bad ratings make the developers of the apps unhappy, and application developers don't like to be unhappy, so they don't make the users do things that they don't want to do.

So, some ways that apps that do time out session but don't require repeated logins might manage this would be, for instance, storing credentials directly, and using them to obtain a session token each time they need one, (not great) or they may be retrieving a long-lived authentication token on first use that they can store as a surrogate credential, and use that token to retrieve a short-lived session token when the app is used. (better option.)

| improve this answer | |
  • 1
    May I suggest addind one schema that I´ve also already seen and is better thant those you cited: when you use a token, the Webservice may warn tthe client (ex using a header in response) that the token is expiring. And then the client can use the token he has to get a new one. – CristianTM Jun 10 '16 at 17:04
  • @CristianTM That's a good thing to mention explicitly. It can be a variation on the second scheme I mention, (which was one of the reasons I suggested it was better than stored raw credentials) or could be used in a single token scheme, which wouldn't be as ideal. – Xander Jun 10 '16 at 17:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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