In what cases is it ok keep a user logged in or provide auto login if an app starts?

Question

I am wondering what the difference is between WhatsApp and my Bank application, and what considerations determine what is the right approach to handle user authentication.

WhatsApp:

• I create my account and don't have to login again
• I change phone but keep my old number (same chip)
• WhatsApp sends me a code because it is the same number and my account is active again
• If my wife/girlfriend/mother/coworker gets the phone, they can see the conversations

BankApp:

• I have to register and create an account with a login/password and use my card number to validate who I am
• They send me an activation link to my email
• I have to enter my login and password every time
• I get logged out after 5 minutes of inactivity
• If a thief points a gun at you, you still will give away the password

I'm developing a tracking app and my first thought was to create a login form so user needs to enter the login/password each time but now I think it is too cumbersome for user. Then I realized WhatsApp never asks me for anything and is always running when I start the phone.

So my approach now is such that the login page only appears once. The user inputs his login and if he is already register on the system, he gets the activation code. The app starts and doesn't ask for login again. The app also sends the ESN number to prove identity.

It is easy to use, but still has a problem if someone gets access to your phone, because they can know where are you been.

But again if they have access to your phone they can browse other things like your Google activity and that seem to be OK because you don't need to enter your password to open Google.

So When is it OK to have a system like WhatsApp, and when a more robust security like the Bank?

Answer 1

Congratulations! You have just given a nice example that different applications with different security requirements use different approaches.

The highest requirements for whatsapp are availability and ease of use because they are targetting end users and assume that they can trade a light confidentiality risk (do not ask password on each new session) for ease of use.

On the other hand a bank application allows for financial operations. Here the most important part is to be sure of who is at the other end of the communication, or at least to be able to prove that they have used state of the art practices to establish it. Because they do not want that another guy could use your smartphone without your explicit permission to transfer money and that you could say (and prove) that you are not at the origin of the transaction. Even if you were forced to give your password because of a rubber hose attack, they will have committen no errors, and won't be liable for any consequences of the operation.

So the rule is: the security rules depend on the security requirements. You know whether for your application, ease of use is more important that security of authentication. I don't.

Answer 2

1. I wouldn't use the ESN number to verify identity, ESN can be forged and can't be revoked if there is a breach/theft. Most services use some sort of secure token that can cryptographically (like an SSL cert) verify identity while also being able to revoked if the private key is compromised.

2. Which approach to recommend depends on the kind of data your app handles. Think about how much of an issue it could cause if someone were to gain unauthorized access to the account. Would it potentially ruin someone's financial status (like a bank account, SSN, etc.) or would it just be a minor inconvenience (someone messes up your saved state on a game). If the damage from a breach would be high, the more security you can provide the better. For some types of data (Financial, Health, etc.) there may be laws dictating this behavior depending on your jurisdiction.

3. Even if your default behavior is to not require login each time, consider making additional security available for the user to turn (require password each time, 2 factor auth, etc.) some users like having good security even if the data isn't that important.