Security and authentication usually end in an annoyance for users and developers but unless everyone in the world pinky swears they won’t do anything bad we need to protect users from bad actors in the system.
The degree of security required is normally based upon the sensitivity of the data being used. However I always tend to push on the side of caution because if you even leak something as simple as an email address that is probably public anyway, the trust in your app will plummet.
Mobiles also provide another interesting aspect, they can be stolen and shared between employees or friends.
Common Attack Vectors
- Phone Stolen or Left Unattended
- Escalation of permissions
- Data leakage
- Compromised Network (Eavesdropping)
Phone Stolen or Left Unattended
You need to prepared that the phone may be left unattended or stolen even while the phone is unlocked and the app is running. Its a worst case scenario and there isn’t much you can do about the initial damage. Here is how you can limit the damage.
#1 – Limit the token validity length. Depending on the sensitivity of the information it could be down to 5 minutes.
#2 – Initiate a log off OnSleep. When the device goes to sleep or is locked, perform a logoff which includes deleting the current token.
#3 – Token’s on the API need to have the ability to deactivate them. For example a flag on the user record to indicate a password change or similar and that previously given out token’s will all invalidate. This provides emergency locking of that account.
Escalation of Permissions
When a mobile phone is shared with employees, an employee might have more permissions more than someone else who also uses that phone. You have two options here of either delete local data they shouldn’t see, or encrypt it to a logged in user. I am of the delete persuasion as its rather fool proof if the delete is successful and caches are cleaned as well, encryption can be broken.
Be sure to clear all cached credential data and clear your model’s state if a new user logs in or upon log out. This keeps potential permission escalation to a minimum.
This is when people who shouldn’t have access to certain bits of data can come across it if not secured properly.
- Another user on the phone with higher permissions logs in and downloads more secure content, that is cached locally.
- The data stored is moved into external storage.
Ways to avoid data leakage are:
- Clear all caches or data downloaded locally on a user logout
- Use SQLCipher or equivalent encryption technology if you must cache locally.
- Use secure storage on each phone to store sensitive information. For some examples look at XLabs Secure Storage.
- Do not store anything to external storage or use a 3rd party app to open data. An example is using an internal PDF Viewer within WebView or implementing your own.
*Note: I am not a security expert and this is not a complete guide for covering all possible attack vectors. For some further reading have a look at the OWASP Mobile App Checklist.
JWT (JSON Web Token)
Here is how JWT works at a very simple level and how the example project also provides security.
Store the token in secure storage and dispose of it when no longer needed.
You will see the AuthenticationService in the example project injects the token into the appropriate repositories when it retrieves a new token. You can extend this to update with refresh tokens as well.
OAuth is a whole security framework involving so much I couldn’t fit it into a reasonable sized blog post. If you have multiple services and possibly multiple authentication servers in an enterprise environment you might want to look into OAuth. If you don’t have the expertise I would suggest looking at a 3rd party provider of OAuth such as Auth0. Otherwise buckle up, get yourself some experts and a lot of development to implement properly.