1

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?

Improve this question
2
  • 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
    Commented Jun 10, 2016 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
    Commented Jun 13, 2016 at 11:00

1 Answer 1

Reset to default
3

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
2
  • 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
    Commented Jun 10, 2016 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
    Commented Jun 10, 2016 at 17:13

You must log in to answer this question.

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