Android Security (Part 1) — Having a Secure User Experience and Securing Shared Preferences
For part one of this series on Android Security, I’m going to go easy on the strict security aspect, for delve a little towards security from a UX perspective. We’ll move gradually towards complicated topics in the articles that follow.
One of the primary aspects of any application these days, is user authentication and sign up. In this article I’m going to mull upon features that would make authentication more secure as well as fast and user friendly.
A lot of the apps that I’ve worked with, use webTokens to authenticate requests, and it’s been a good practice to have tokens for individual users after they’ve authenticated themselves — logged in. Often, these tokens have an expiration date, depending on the the security expectations of the app — a banking app may have a token expiration period of 15–20 minutes, where as a video streaming app may set the expiration to days or weeks.
Most banking and financial apps require users to authenticate themselves every time they open the app, and I’d say it’s a justified method since financial apps demand a certain level of security. Let’s look at way we can make the authentication process simpler for the user in such apps.
Firstly it’s quite tiresome and unnecessary for users to enter their email and password every time they want to see their details. A lot of phones these days support biometric authentication, and I see no reason why developers aren’t taking advantage of these features. Android has inbuilt apis that allow apps to authenticate users by fingerprint, face recognition, etc.
Once the user has signed in once, with his credentials, on to the app, I’d recommend using Biometric authentication for all subsequent instances where authentication is required. A lot of times a new token is provided whenever an authentication request is called, and since we aren’t getting credentials on biometric authentication, we will have to look out for alternate approaches to receive a refreshed token.
The traditional way to get a new token is something like this —
But with Biometric authentication, since we don’t have the credentials, we may ask the server to provide us an updated token, by passing in the last valid token that was received by us.
However this approach comes with a dependency on the server side team to create a mechanism to suit that method. i.e. Provide a new token with username and previous token.
If you want to avoid dependency from other teams and still generate a refreshed token after biometric authentication (refreshing the token by username and password), you have an option of locally storing the username and password on the initial sign in, and using that to subsequently request for a new token, every-time a biometric authentication is successful — although I DO NOT recommend this approach, it serves as a way to ship your product faster, without adding dependency to other teams, who may be busy with something else.
Storing user credentials locally is a vulnerability in itself, but we can secure it by encrypting the data before storing it.
Securing SharedPreferences
Shared preferences are easily accessible, especially if the user is accessing the app with a rooted device. Hence it only makes sense to encrypt data before storing it there. That being said, you’d also want to avoid storing sensitive data in Preferences — like user credentials — but that’s exactly what I’m going to do, just for the sake of demonstration.
There are multiple ways of encryption — and plain Base64 encoding isn’t one of them — and I’m going to share a very basic snippet below.
Another problem that arises is, the encryption key. A user can easily decrypt data if he gets his hands on the encryption key, and hence storing the key in a secure place is crucial. Let’s get to know more about that in the next article.
