Android

Secure communication is the backbone of modern financial app development. HTTPS, powered by TLS (Transport Layer Security), ensures that the data exchanged between your app and its server stays protected from unauthorized access. In this blog, we’ll explore HTTPS communication on Android, focusing on TLS 1.3—the latest and most secure version of the protocol. We’ll guide you through the process of implementing secure communication in Kotlin, simplifying each step with clear, jargon-free explanations.

What is HTTPS and TLS?

HTTPS
HTTPS (Hypertext Transfer Protocol Secure) is an upgrade to HTTP, designed to secure the communication between web clients and servers. It uses TLS (Transport Layer Security) to encrypt the data, protecting it from interception during transmission. This is especially important for safeguarding sensitive details like passwords, payment information, or personal data.

TLS
TLS is a cryptographic protocol that offers three core protections:

• Encryption: Ensures that data remains confidential and cannot be accessed by unauthorized parties.
• Authentication: Confirms that the server is legitimate and, optionally, verifies the client’s identity.
• Integrity: Guarantees that the data hasn’t been modified during transmission.

TLS 1.3
TLS 1.3, the latest version of the protocol, brings several key enhancements:

• Improved Handshake Performance: Reduces the time needed to establish a secure connection.
• Stronger Encryption: Implements more robust encryption methods for better security.
• Simplified Protocol: Strips away outdated features, reducing potential vulnerabilities.

Why HTTPS and TLS 1.3?

HTTPS
As the secure version of HTTP, HTTPS uses TLS to encrypt the data exchanged between the app and the server. In the context of financial applications, HTTPS offers:

• Confidentiality: Safeguards sensitive information like user credentials and transaction data from being intercepted.
• Data Integrity: Ensures the information sent and received is unchanged during transit.
• Server Authentication: Verifies the authenticity of the server, helping protect against fraud and man-in-the-middle attacks.

TLS 1.3
TLS 1.3, released in 2018, brings numerous advantages over previous versions:

• Stronger Security: Phases out older, vulnerable protocols such as RSA key exchange, making the connection more secure.
• Faster Handshakes: Simplifies the connection process, improving speed and reducing delay.
• Forward Secrecy: Even if an attacker gains access to a server’s private key, past communication remains secure.

For financial apps, using TLS 1.3 is essential to ensure both robust security and a smooth, responsive user experience.

Setting Up HTTPS in Android Apps

Android natively supports HTTPS, but to make sure your app works with TLS 1.3, you’ll need to configure a few settings and understand the requirements.

Prerequisites

• Make sure your app is targeting Android 10 (API level 29) or higher, as this version comes with native support for TLS 1.3.
• Install a valid SSL certificate on the server hosting your APIs to establish secure communication.

Step-by-Step Implementation

// Use the latest version in the future.
implementation("com.squareup.okhttp3:okhttp:4.12.0") 
implementation("com.google.code.gson:gson:2.12.0")

We’ll utilize OkHttp for handling HTTPS requests, as it offers a lightweight and efficient solution.

Creating a Secure HTTP Client

To enable HTTPS with TLS 1.3, configure OkHttp’s OkHttpClient. This client will handle secure communication with your backend.

import okhttp3.OkHttpClient
import okhttp3.Request
import okhttp3.Response
import java.util.concurrent.TimeUnit

fun createSecureHttpClient(): OkHttpClient {
    return OkHttpClient.Builder()
        .connectTimeout(30, TimeUnit.SECONDS)
        .readTimeout(30, TimeUnit.SECONDS)
        .writeTimeout(30, TimeUnit.SECONDS)
        .build()
}

Here,

• connectTimeout: The maximum duration allowed for establishing a connection.
• readTimeout: The maximum time allowed to wait for data after the connection is established.
• writeTimeout: The maximum time allowed to wait while sending data to the server.

With Android 10 and higher versions supporting TLS 1.3 natively, no extra configuration is needed for the protocol. The OkHttp client automatically negotiates the highest version it supports.

For older Android versions, ensure that the device is using the latest system libraries, or incorporate third-party TLS solutions such as Conscrypt to enable support for newer TLS protocols like TLS 1.2 or TLS 1.3.

Making Secure HTTPS Requests

Once the client is ready, use it to make API requests.

import okhttp3.OkHttpClient
import okhttp3.Request
import org.json.JSONObject

fun makeSecureRequest(client: OkHttpClient) {
    val request = Request.Builder()
        .url("https://yourfinancialdomain.com/api/endpoint")
        .get()
        .build()

    client.newCall(request).execute().use { response ->
        if (response.isSuccessful) {
            val jsonResponse = JSONObject(response.body?.string() ?: "")
            println("Response: $jsonResponse")
        } else {
            println("Error: ${response.code}")
        }
    }
}

• Request Building: Defines the target URL and HTTP method (GET in this case).
• Response Handling: Reads and parses the server’s response. Always handle errors to ensure reliability.

Key Points About TLS 1.3

• Backward Compatibility: TLS 1.3 supports backward compatibility with older versions (like TLS 1.2) by negotiating the highest mutually supported version.
• Performance: TLS 1.3 reduces round-trip times (RTTs) during handshakes, resulting in faster connection establishment, making it ideal for mobile apps.
• Security: TLS 1.3 deprecates weak cryptographic algorithms and only supports modern, secure encryption methods, ensuring enhanced security.

Testing HTTPS Communication

• Use Postman: Test your API endpoints, ensuring valid certificates are used and checking SSL/TLS connection aspects like certificate trust and hostname verification.
• Validate Pinning: Validate certificate pinning by changing the server’s certificate and ensuring that the client rejects untrusted connections. Ensure both server and client-side pinning implementations are correctly configured.
• Check TLS Version: Check the TLS version using tools like Wireshark, which can capture network traffic and verify if TLS 1.3 is being used, or use OpenSSL for command-line verification.

Best Practices for Secure HTTPS Communication

• Use Strong Encryption: Always enable the latest TLS protocols (preferably TLS 1.2 or 1.3) and ensure strong cipher suites are used for secure communication.
• Avoid Hardcoding Keys: Avoid hardcoding keys and sensitive data in your source code; use secure storage mechanisms like Android Keystore, EncryptedSharedPreferences, or secure servers to store such information.
• Monitor Dependencies: Monitor and regularly update libraries (e.g., OkHttp, Retrofit) to patch vulnerabilities. Use tools like Dependabot to stay up to date with security updates.
• Implement Error Handling: Implement robust error handling to manage network issues gracefully without exposing sensitive information. Provide meaningful feedback to users without revealing implementation details or errors.

Conclusion

Secure HTTPS (TLS 1.3) communication isn’t just a best practice — it’s a must for financial Android apps. With Kotlin and powerful tools like OkHttp, you can easily implement top-tier security without the hassle. By following these steps, you’ll not only protect sensitive data but also earn your users’ trust every step of the way.

Let’s secure the financial world, one app at a time..!

In today’s connected world, securing app communication is a top priority for Android developers. Whenever your app exchanges data with a server, there’s a risk that attackers could intercept and alter this information. A reliable way to guard against this is by using certificate pinning. This security measure helps protect your app from Man-in-the-Middle (MITM) attacks, which aim to intercept the communication between your app and its server.

In this guide, we’ll explore what certificate pinning involves, why it’s an essential security practice for Android apps, and how to set it up in Kotlin. By the end, you’ll be equipped with the knowledge to implement certificate pinning in your projects and bolster your app’s security. Let’s get started!

What is Certificate Pinning?

Certificate pinning is a security measure that ensures our app only trusts specific SSL/TLS certificates for a given domain, instead of relying solely on certificates issued by Certificate Authorities (CAs). This guarantees that our app communicates securely with the intended server and not with a fake or malicious one.

Wait, wait—what exactly are SSL/TLS certificates, and who are Certificate Authorities (CAs)? These terms might sound familiar, but let’s break them down in simple terms. To make things clearer, let’s first look at the basic concept of a secure connection, using an everyday example.

Imagine you’re visiting a coffee shop. You trust the barista because you’ve been coming there for years. But how do you know you’re talking to the right person when they serve you your coffee? You check their name tag — it’s a simple form of identification. In the digital world, this “name tag” is an SSL/TLS certificate, which proves the identity of the server you’re connecting to.

Now, who gives the barista their name tag? In the digital world, that’s the role of Certificate Authorities (CAs). These trusted entities issue and verify certificates, ensuring that the server you’re connecting to is actually the one it claims to be.

Once you understand this basic “handshake” concept, you’ll see how certificate pinning adds an additional layer of security — ensuring your app always talks to the right server, using only a specific certificate, and not a potential imposter.

What Makes Certificate Pinning Essential?

Certificate Pinning is a security technique that binds or “pins” your app to a specific server certificate. Instead of trusting any certificate signed by a recognized Certificate Authority (CA), the app is set up to accept only a specific certificate or public key. This means that if a CA is compromised or a fraudulent certificate is used, your app will detect the mismatch and reject the connection.

When your app communicates with a server, it typically relies on HTTPS to encrypt and secure the data exchange. While HTTPS provides strong protection, it still has vulnerabilities—like the risk of malicious CAs issuing fake certificates that attackers could use to intercept sensitive data. Certificate Pinning protects against this by validating only the exact certificate your app should trust, making it much harder for attackers to impersonate your server.

By default, Android apps trust a broad set of CAs, which means that if any of these is compromised, a malicious actor could intercept the app-server communication. By using Certificate Pinning, your app trusts only specific certificates, reducing the risk of Man-in-the-Middle (MITM) attacks and keeping your data exchanges more secure.

Implementing Certificate Pinning in Android

Let’s dive into how to implement certificate pinning in an Android app using Kotlin. We’ll go through a step-by-step approach to setting up and verifying certificates with the OkHttp library, a popular HTTP client library for Android.

Identify the Server Certificate

Before implementing Certificate Pinning, you need the certificate’s public key or SHA-256 hash. You can use tools like browsers or OpenSSL to extract this information.

openssl s_client -connect google.com:443 -showcerts

Or use a browser,

Add OkHttp Dependency

Nest, add OkHttp and OkHttp-TLS dependency in your build.gradle file to manage network operations with certificate pinning support.

implementation("com.squareup.okhttp3:okhttp:4.9.3")
implementation("com.squareup.okhttp3:okhttp:4.9.3-tls")

Set Up Certificate Pinning in OkHttp

Now, let’s configure certificate pinning using the SHA-256 fingerprint obtained earlier.

import okhttp3.OkHttpClient
import okhttp3.Request
import okhttp3.CertificatePinner

fun createPinnedOkHttpClient(): OkHttpClient {
    // Define the certificate pin for your server
    val certificatePinner = CertificatePinner.Builder()
        .add("yourserver.com", "sha256/YourCertificateSHA256FingerprintHere")
        .build()

    // Configure OkHttpClient with certificate pinning
    return OkHttpClient.Builder()
        .certificatePinner(certificatePinner)
        .build()
}

fun makeSecureRequest() {
    val client = createPinnedOkHttpClient()
    val request = Request.Builder()
        .url("https://yourserver.com/api/endpoint")
        .build()

    // Make the secure request
    client.newCall(request).execute().use { response ->
        if (response.isSuccessful) {
            println("Response: ${response.body?.string()}")
        } else {
            println("Failed to fetch data: ${response.code}")
        }
    }
}

Here,

CertificatePinner Configuration:

• First, we create an instance of CertificatePinner.
• We use the add() method to define a specific certificate pin for our server. Replace "yourserver.com" with your actual server’s domain and "sha256/YourCertificateSHA256FingerprintHere" with your SHA-256 certificate fingerprint. This fingerprint serves as the unique identifier that OkHttp will use to verify the server’s authenticity.

OkHttpClient Configuration:

• Next, we configure an OkHttpClient instance and set the certificatePinner to it. This ensures that any requests made through this client will only trust the pinned certificate. If the server presents a certificate that doesn’t match the pinned one, OkHttp will throw an exception and reject the connection.

Making a Secure Request:

• Finally, we create a request with the secure OkHttpClient instance configured with our certificate pinner. This request attempts to connect to https://yourserver.com/api/endpoint.
• Upon receiving the response, we check if it’s successful. If the certificate matches, data is retrieved; if it doesn’t match, an exception is raised, preventing insecure data exchanges.

Handling Multiple Pinning with Backup Certificates

What happens if your server’s certificate is updated or rotated? This is where backup pinning comes into play. By pinning multiple certificates or public keys, you allow your app to connect even if one certificate changes.

fun pinMultipleCertificates() {
    val certificatePinner = CertificatePinner.Builder()
        .add("your-website.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")  // Old pin
        .add("your-website.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=")  // New pin
        .build()

    val client = OkHttpClient.Builder()
        .certificatePinner(certificatePinner)
        .build()

    val request = Request.Builder()
        .url("https://your-website.com/api/endpoint")
        .build()

    client.newCall(request).execute().use { response ->
        if (!response.isSuccessful) throw IOException("Unexpected code $response")
        println(response.body!!.string())
    }
}

This ensures that if your certificate rotates, the app will still trust the new certificate as long as its public key hash is pinned.

Dynamically Pinning Certificates

In some scenarios, it might be necessary to pin certificates dynamically, particularly when working with multiple environments or during development. You can achieve this by fetching the certificate hash at runtime.

fun getPinnedCertificate(environment: String): String {
    return when (environment) {
        "production" -> "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
        "staging" -> "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
        else -> throw IllegalArgumentException("Unknown environment")
    }
}

fun pinCertificateDynamically(environment: String) {
    val pin = getPinnedCertificate(environment)
    val certificatePinner = CertificatePinner.Builder()
        .add("your-website.com", pin)
        .build()

    val client = OkHttpClient.Builder()
        .certificatePinner(certificatePinner)
        .build()

    val request = Request.Builder()
        .url("https://your-website.com/api/endpoint")
        .build()

    client.newCall(request).execute().use { response ->
        if (!response.isSuccessful) throw IOException("Unexpected code $response")
        println(response.body!!.string())
    }
}

Here, the correct pin is selected based on the environment, giving you flexibility across various stages of development and deployment.

Challenges and Considerations

While certificate pinning is a powerful tool for securing your app, there are a few challenges and considerations to keep in mind:

• Updating pins: If the server’s certificate needs to be changed (for example, when the certificate expires), we’ll need to update the pinned certificate in the app and release a new version. This means we must ensure the certificate is updated regularly and we have a good process in place for deploying new app versions.
• Risk of breakage: If the pinning is too strict, we might face situations where legitimate changes to the server’s certificate (e.g., switching to a different CA) could break the connection. This is why it’s important to monitor certificate changes and have an update strategy.
• Backup mechanism: We can implement a backup mechanism to allow updates to the certificate pin during runtime, giving us flexibility without forcing users to update the app every time a pin change occurs.

Best Practices

Here are a few best practices to ensure we’re using certificate pinning effectively:

1. Pin multiple certificates: It’s a good idea to pin more than one certificate or public key. This gives us flexibility in case of certificate rotation or renewal without breaking the app’s functionality.

2. Handle certificate expiry gracefully: Plan for certificate expiration by regularly rotating certificates and testing your app with updated pins before they expire.

3. Hardcoding Pins: Avoid hardcoding pins in your app for security reasons. If the app is decompiled, attackers can retrieve the pinned certificate hash. Consider dynamically fetching pins or using obfuscation techniques to secure your app.

4. Managing Multiple Environments: As demonstrated earlier, dynamically switching pins based on environments (development, staging, production) is crucial. Be careful not to expose development pins in production environments.

5. Monitor and audit pins: Regularly audit your pinned certificates to ensure they’re up-to-date and match the server’s current certificates. You can also use logging to track failed pin validation attempts.

6. Fallback to normal SSL checks: In cases where pinning fails, allow the app to fall back to the standard SSL/TLS verification to avoid completely blocking the user.

Conclusion

Certificate pinning is a vital security practice for any Android app that exchanges sensitive information over the network. By enforcing a strict check on the server’s certificate, you can significantly reduce the risk of MITM attacks. 

In this guide, we explored how to set up certificate pinning using Kotlin and OkHttp. Implementing certificate pinning might seem a bit complex at first, but it’s a worthy investment in the long run. It gives your users confidence that their data is secure, especially in an age where data breaches are increasingly common. Give certificate pinning a try in your Android project to keep your app secure and trustworthy!

In Android app development, data security is a top priority, especially when working with sensitive information. Protecting user data from unauthorized access and misuse is a responsibility we can’t overlook. In this guide, I’ll walk you through practical methods to secure data in Android apps, and show you how to implement these techniques effectively in your projects.

We’ll start with Local Session Timeouts to limit data exposure during inactivity, then move on to Disabling App Data Backup to keep sensitive data out of potentially insecure backups. Next, we’ll discuss Protecting Configuration Data to secure app settings, In-Memory Sensitive Data Holding to prevent unintentional leaks, and finally, Secure Input for PIN Entry to guard against interception. Each section is crafted to help you build more robust and secure Android apps. Let’s dive in!

Data Security

Data security is all about keeping user information safe, whether it’s stored (at rest) or moving from one place to another (in transit). This means using encryption to protect data, securely storing it, and handling sensitive information with extra care.

Local Session Timeout

A local session timeout is a security feature that helps keep user data safe by tracking inactivity. If a user hasn’t interacted with the app for a set amount of time, the app will automatically log them out. This feature is especially important in financial apps, where protecting sensitive information is a top priority.

In financial apps, leaving a session open can be a serious security risk. If someone else picks up the user’s phone, they could access the app and potentially perform unauthorized actions. By adding a session timeout, we:

• Reduce the risk of unauthorized access,
• Safeguard sensitive financial data, and
• Ensure compliance with security standards in the financial industry.

To implement a local session timeout in Kotlin, we can use a CountDownTimer that resets each time the user interacts with the app.

const val TIMEOUT_DURATION = 5 * 60 * 1000L // 5 minutes in milliseconds


class SessionManager(private val context: Context) {

    private var timer: CountDownTimer? = null

    // Start or restart the inactivity timer
    fun startSessionTimeout() {
        timer?.cancel() // cancel any existing timer
        timer = object : CountDownTimer(TIMEOUT_DURATION, 1000L) {
            override fun onTick(millisUntilFinished: Long) {
                // Optionally, add logging or other feedback here
            }

            override fun onFinish() {
                onSessionTimeout()
            }
        }.start()
    }

    // Reset the timer on user interaction
    fun resetSessionTimeout() {
        startSessionTimeout()
    }

    // Handle session timeout (e.g., log the user out)
    private fun onSessionTimeout() {
        // Example action: Redirect to login screen
        context.startActivity(Intent(context, LoginActivity::class.java).apply {
            flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK
        })
    }

    // Cancel the timer when the session ends
    fun endSession() {
        timer?.cancel()
    }
}

class MainActivity : AppCompatActivity() {

    private lateinit var sessionManager: SessionManager

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        sessionManager = SessionManager(this)

        // Start the session timer when the activity is created
        sessionManager.startSessionTimeout()
    }

    override fun onUserInteraction() {
        super.onUserInteraction()
        // Reset the session timeout on any user interaction
        sessionManager.resetSessionTimeout()
    }

    override fun onDestroy() {
        super.onDestroy()
        // End the session when the activity is destroyed
        sessionManager.endSession()
    }
}

• startSessionTimeout(): Starts a countdown timer that will log the user out after the set duration.
• onUserInteraction(): Resets the timer whenever the user interacts with the app to prevent unintended logouts.

Disabling App Data Backup

When building financial apps, security should always be a top priority. Sensitive information like banking credentials, personal details, and financial records must be protected at all costs. One often-overlooked security measure is disabling app data backups. While Android’s automatic cloud backup feature is convenient, it can expose sensitive data if not managed properly.

By default, Android automatically backs up an app’s data to Google Drive, including SharedPreferences, files, and other persistent data. This process is controlled by the android:allowBackup attribute in the app’s AndroidManifest.xml. By setting this attribute to false, the app ensures its data is not backed up, which is essential for securing financial apps and other apps that handle sensitive information.

<application
    android:name=".FinancialApp"
    android:allowBackup="false"
    android:fullBackupContent="false"
    ... >
    <!-- other configurations -->
</application>

android:allowBackup=”false”: Prevents Android from backing up any data from this app.

android:fullBackupContent=”false”: Ensures that no full data backup occurs, even if the device supports full data backups.

While both allowBackup="false" and fullBackupContent="false" significantly reduce the chances of unauthorized backups and data exposure, they do not provide 100% protection, especially on rooted or compromised devices. That’s why, in financial apps, we check if the device is rooted and implement additional tampering checks to enhance security.

Configuration Data Protection

Sensitive configuration data, like API keys or access tokens, shouldn’t be hardcoded directly into the app. Instead, it’s safer to encrypt them or store them securely in the Android Keystore, which serves as a secure container for cryptographic keys. Hardcoding sensitive information exposes it to potential attackers, who can easily extract it from the app’s binary. In contrast, the Android Keystore provides tamper-resistant storage, ensuring that your sensitive data remains protected.

Encrypted SharedPreferences

SharedPreferences is commonly used to store small data values in Android, but the issue with standard SharedPreferences is that it saves data in plain text, which is vulnerable if the device is compromised. For sensitive data like API keys or user credentials, it’s best to use EncryptedSharedPreferences, which ensures your data is encrypted and stored securely. Let’s take a look at how to implement this.

import androidx.security.crypto.EncryptedSharedPreferences
import androidx.security.crypto.MasterKeys

fun getSecureSharedPreferences(context: Context): SharedPreferences {
    val masterKeyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)

    return EncryptedSharedPreferences.create(
        "secure_preferences", // Name of the preferences file
        masterKeyAlias, // The master key for encryption
        context,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )
}

fun saveConfigData(context: Context, apiKey: String) {
    val sharedPreferences = getSecureSharedPreferences(context)
    with(sharedPreferences.edit()) {
        putString("api_key", apiKey)
        apply() // Save the data securely
    }
}

fun getConfigData(context: Context): String? {
    val sharedPreferences = getSecureSharedPreferences(context)
    return sharedPreferences.getString("api_key", null) // Retrieve the secure data
}

Here,

• MasterKeys.getOrCreate() creates a master key using AES-256 encryption. This key is used to encrypt the data.
• EncryptedSharedPreferences.create() initializes the EncryptedSharedPreferences instance with the specified encryption schemes for both the keys and values.
• putString() securely saves sensitive data like API keys, while getString() retrieves the encrypted value.

Encrypting API Keys and Tokens

Hardcoding API keys and tokens directly into your app’s code can create serious security vulnerabilities. If someone decompiles your app or gains unauthorized access, these sensitive credentials could be exposed. Instead, it’s safer to store them in an encrypted format and decrypt them only when needed during runtime.

Here’s how you can use AES encryption in Kotlin to securely handle your API keys and tokens.

import javax.crypto.Cipher
import javax.crypto.KeyGenerator
import javax.crypto.SecretKey
import javax.crypto.spec.GCMParameterSpec
import android.util.Base64

// Encrypting a string with AES
fun encryptData(plainText: String, secretKey: SecretKey): String {
    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    cipher.init(Cipher.ENCRYPT_MODE, secretKey)
    val iv = cipher.iv
    val encryptedData = cipher.doFinal(plainText.toByteArray())
    val ivAndEncryptedData = iv + encryptedData
    return Base64.encodeToString(ivAndEncryptedData, Base64.DEFAULT)
}

// Decrypting the encrypted string
fun decryptData(encryptedText: String, secretKey: SecretKey): String {
    val ivAndEncryptedData = Base64.decode(encryptedText, Base64.DEFAULT)
    val iv = ivAndEncryptedData.sliceArray(0 until 12) // Extract the 12-byte IV
    val encryptedData = ivAndEncryptedData.sliceArray(12 until ivAndEncryptedData.size)
    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    val gcmParameterSpec = GCMParameterSpec(128, iv) // 128-bit authentication tag length
    cipher.init(Cipher.DECRYPT_MODE, secretKey, gcmParameterSpec)
    val decryptedData = cipher.doFinal(encryptedData)
    return String(decryptedData)
}

// Generate Secret Key for AES
fun generateSecretKey(): SecretKey {
    val keyGenerator = KeyGenerator.getInstance("AES")
    keyGenerator.init(256) // AES 256-bit encryption
    return keyGenerator.generateKey()
}

• AES/GCM/NoPadding: This mode provides strong encryption and also ensures no unnecessary padding is added, keeping the data size as small as possible.
• Initialization Vector (IV): The IV is crucial for ensuring that even if the same data is encrypted multiple times, the output will differ. It’s stored alongside the encrypted data and is required for decryption.
• generateSecretKey(): This method creates a 256-bit AES key, which can be used for both encryption and decryption. To further enhance security, you can store this key in the Android Keystore.

Android Keystore for Secure Key Management

Storing encryption keys directly in the app can leave them vulnerable to attacks. To avoid this, we can use the Android Keystore system, which securely stores keys either in hardware or a secure enclave, ensuring that only the app has access to them. This adds a significant layer of protection, especially for sensitive data.

Here’s how you can generate and securely manage keys using the Keystore:

import android.security.keystore.KeyGenParameterSpec
import android.security.keystore.KeyProperties
import java.security.KeyStore
import javax.crypto.KeyGenerator
import javax.crypto.SecretKey

// Generate and store a key in Android Keystore
fun createKey() {
    val keyGenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
    val keyGenParameterSpec = KeyGenParameterSpec.Builder(
        "SecureKeyAlias",
        KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
    ).setBlockModes(KeyProperties.BLOCK_MODE_GCM)
     .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
     .build()
    keyGenerator.init(keyGenParameterSpec)
    keyGenerator.generateKey()
}

// Retrieve the secret key from Keystore
fun getSecretKey(): SecretKey? {
    val keyStore = KeyStore.getInstance("AndroidKeyStore")
    keyStore.load(null)
    return keyStore.getKey("SecureKeyAlias", null) as SecretKey?
}

• KeyGenParameterSpec.Builder: This part sets the encryption requirements, such as the encryption block mode and padding. In this case, we’re using AES with GCM mode, which is both secure and efficient.
• createKey(): This function creates a new AES encryption key and securely stores it in the Keystore with the alias SecureKeyAlias. The key is only accessible to the app, making it safe from potential leaks.
• getSecretKey(): This function retrieves the stored key from the Keystore when needed for encryption or decryption. The key is never exposed in the code, adding an extra layer of security.

Secure In-Memory Sensitive Data Holding

When your app processes sensitive information like user session tokens, PINs, or account numbers, this data is temporarily stored in memory. If this information is kept in memory for too long, it becomes vulnerable to unauthorized access—especially in rooted or debug-enabled environments where attackers could potentially retrieve it from other applications. Financial apps are particularly at risk because they handle highly sensitive data, so securing session tokens, PINs, and account numbers in memory is essential for protecting user privacy and minimizing exposure to attacks.

Best Practices for Securing In-Memory Data in Android

To keep session tokens, PINs, account numbers, and other sensitive data safe in memory, consider these three core principles:

Minimal Data Exposure: Only keep sensitive data in memory for as long as absolutely necessary, and clear it promptly once it’s no longer needed.

fun performSensitiveOperation() {
    val sensitiveData = fetchSensitiveData() // Example: fetching from secure storage
    try {
        // Use the sensitive data within a limited scope
        processSensitiveData(sensitiveData)
    } finally {
        // Clear sensitive data once it's no longer needed
        sensitiveData.clear()
    }
}

Data Clearing: Ensure that sensitive data is swiftly and thoroughly cleared from memory when it’s no longer required. We can use ByteArray and clear the data immediately after use.

class SensitiveDataHandler {

    fun processSensitiveData(data: ByteArray) {
        try {
            // Process the sensitive data securely
        } finally {
            data.fill(0) // Clear data from memory immediately
        }
    }
}

Obfuscation: Make it difficult for attackers to make sense of session tokens, PINs, or account numbers if they gain access to memory.

Secure Input for PIN Entry

Imagine a user is logging into their banking app while grabbing coffee in a crowded cafe. They quickly type in their PIN, maybe not noticing someone glancing over their shoulder — or that a vulnerability in the app could put their data at risk. That’s exactly why secure PIN entry is so important, especially in financial apps where a PIN is more than just a few numbers; it’s a gateway to sensitive information.

To securely capture PINs, use Android’s secure input types, and avoid storing PINs in plain text. Always hash sensitive data and use Base64 encoding before encrypting and storing it.

import android.content.Context
import android.text.InputType
import android.widget.EditText
import androidx.security.crypto.EncryptedSharedPreferences
import androidx.security.crypto.MasterKeys
import java.security.MessageDigest
import java.util.*

class SecurePinManager(context: Context) {
    private val masterKeyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)
    private val encryptedPrefs = EncryptedSharedPreferences.create(
        "secure_prefs",
        masterKeyAlias,
        context,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun setupPinInputField(editText: EditText) {
        editText.inputType = InputType.TYPE_CLASS_NUMBER or InputType.TYPE_NUMBER_VARIATION_PASSWORD
    }

    fun savePin(pin: String) {
        val hashedPin = hashPin(pin) // Hash the PIN before saving
        encryptedPrefs.edit().putString("user_pin", hashedPin).apply()
    }

    fun verifyPin(inputPin: String): Boolean {
        val storedHashedPin = encryptedPrefs.getString("user_pin", null)
        val inputHashedPin = hashPin(inputPin) // Hash the input before comparison
        return storedHashedPin == inputHashedPin
    }

    // Hashes the PIN using SHA-256
    private fun hashPin(pin: String): String {
        val digest = MessageDigest.getInstance("SHA-256")
        val hashedBytes = digest.digest(pin.toByteArray())
        return Base64.getEncoder().encodeToString(hashedBytes) // Encode the hashed bytes in Base64
    }
}

Here,

• PIN Hashing: The PIN is now hashed using SHA-256 before saving and comparing. This adds a layer of security by ensuring the raw PIN is never stored.
• Base64 Encoding: The hashed PIN is encoded using Base64 to store it as a string in EncryptedSharedPreferences.

Conclusion

Securing sensitive data in Android requires a combination of best coding practices and taking advantage of built-in security features. Here’s a quick recap of the key points we covered:

• Local Session Timeout: Automatically log users out after a period of inactivity to reduce the risk of unauthorized access.
• Disabling App Data Backup: Prevent backups of sensitive data, ensuring that it doesn’t get exposed in case of a backup breach.
• Configuration Data Protection: Encrypt configuration data to keep it safe from unauthorized access.
• Secure In-Memory Data Holding: Only store sensitive data in memory when absolutely necessary, and make sure it’s cleared once it’s no longer needed.
• Secure Input for PIN Entry: Use secure input types and enable accessibility settings to protect PIN entries from being exposed.

By implementing these simple practices, you can create a more secure and trustworthy Android app. For apps handling sensitive data, these steps are crucial to ensuring that user information stays private and safe!

Imagine a user is logging into their banking app while grabbing coffee in a crowded cafe. They quickly type in their PIN, maybe not noticing someone glancing over their shoulder — or that a vulnerability in the app could put their data at risk. That’s exactly why Secure Input for PIN Entry is so important, especially in financial apps where a PIN is more than just a few numbers; it’s a gateway to sensitive information.

In this guide, we’ll build a secure PIN entry system for Android. I’ll walk you through the Kotlin code step-by-step, along with key security tips. So stay tuned..!

Why is Secure PIN Entry So Important?

In financial apps, PINs are often the key to user authentication, making secure PIN entry essential. Here’s why it matters:

• Prevent Shoulder Surfing: Stop others from sneaking a peek at the PIN in crowded or public spaces.
• Block Unauthorized Access: Strengthen PIN handling to eliminate weak security points.
• Protect Against Data Leaks: Safeguard sensitive data by avoiding insecure storage or logging practices.

Best Practices for Secure Input for PIN Entry

1. Use a Custom View for Input Masking
   • Default Android input views may not be secure enough, as they’re designed for generic inputs. Creating a custom view for PIN entry adds control over how data is handled and stored.
2. Minimize PIN Storage Duration
   • Store PIN data in memory only as long as needed. Clear it from memory once used.
3. Use Secure Storage for Sensitive Data
   • Don’t store the PIN itself; instead, use tokens or session IDs post-authentication.
4. Disable Screenshots
   • Prevent screenshots and screen recording to avoid capturing the PIN on-screen.
5. Avoid Logging Sensitive Data
   • Ensure that the PIN isn’t logged or displayed in the logcat.
6. Use Obfuscation Techniques
   • Obfuscate sensitive parts of the codebase to make reverse engineering harder.

Implementing Secure PIN Entry in Kotlin

Alright, without wasting time, let’s jump into the Kotlin code and start building our secure PIN entry feature.

Disable Screenshots

Preventing screenshots and screen recording ensures that no sensitive data gets captured visually.

In your Activity class, disable screenshots by adding this line in the onCreate method.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    window.setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE)
    setContentView(R.layout.activity_pin_entry)
}

The FLAG_SECURE flag prevents the app from taking screenshots or recording the screen when the PIN entry screen is open.

Create a Custom PIN Entry View

A custom PIN entry view allows us to control how each input character behaves and ensures that data is stored only in memory for the duration needed.

Create a SecurePinEntryView class that extends LinearLayout.

class SecurePinEntryView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = 0
) : LinearLayout(context, attrs, defStyleAttr) {

    private val pinDigits = mutableListOf<EditText>() // Holds the EditTexts for each PIN digit
    private val maxPinLength = 4 // Number of PIN digits

    init {
        orientation = HORIZONTAL
        setupPinFields()
    }

    private fun setupPinFields() {
        for (i in 0 until maxPinLength) {
            val digitField = createDigitField()
            pinDigits.add(digitField)
            addView(digitField)
        }
    }

    private fun createDigitField(): EditText {
        return EditText(context).apply {
            inputType = InputType.TYPE_CLASS_NUMBER or InputType.TYPE_NUMBER_VARIATION_PASSWORD
            setBackgroundColor(Color.TRANSPARENT)
            filters = arrayOf(InputFilter.LengthFilter(1))
            isCursorVisible = false
            textAlignment = View.TEXT_ALIGNMENT_CENTER
            layoutParams = LayoutParams(0, LayoutParams.MATCH_PARENT, 1f) // Distribute space evenly

            setOnFocusChangeListener { _, hasFocus ->
                if (hasFocus && text.isEmpty()) {
                    this.text.clear() // Clear text only if empty to avoid accidental deletion
                }
            }
        }
    }

    // Collects the PIN entered by the user
    fun getPin(): String {
        return pinDigits.joinToString("") { it.text.toString() }
    }

    // Clears the entered PIN
    fun clearPin() {
        pinDigits.forEach { it.text.clear() }
    }
}

Here,

• Orientation & Style: We set the orientation to HORIZONTAL to align the PIN digits in a row.createDigitField(): Creates a customized EditText for each PIN digit.
• InputType.TYPE_NUMBER_VARIATION_PASSWORD hides the PIN visually by displaying dots.
• Each digit field is limited to one character using InputFilter.LengthFilter(1).
• isCursorVisible is set to false to remove the blinking cursor, which makes it harder for onlookers to see which digit is currently being entered.

Handle PIN Submission

Once the user enters the PIN, we’ll verify it securely. Here’s an example of how to collect and handle the PIN securely.

val securePinEntryView = findViewById<SecurePinEntryView>(R.id.securePinEntryView)
val submitButton = findViewById<Button>(R.id.submitButton)

submitButton.setOnClickListener {
    val enteredPin = securePinEntryView.getPin()
    
    // Verify the PIN here or pass it to the next step
    if (verifyPin(enteredPin)) {
        // Handle successful PIN entry
        Toast.makeText(this, "PIN verified!", Toast.LENGTH_SHORT).show()
    } else {
        // Clear PIN for incorrect attempts
        securePinEntryView.clearPin()
        Toast.makeText(this, "Incorrect PIN. Try again.", Toast.LENGTH_SHORT).show()
    }
}

private fun verifyPin(pin: String): Boolean {
    // Replace this with actual PIN verification logic
    return pin == "1234" // Example PIN for demonstration
}

In this code,

• getPin(): Collects the entered PIN from the custom view.
• verifyPin(): Checks if the entered PIN matches the stored PIN. In a real application, use a secure method to validate the PIN.

Clear PIN on Incorrect Attempts

Clearing the PIN on incorrect attempts prevents attackers from guessing and observing patterns.

private fun handleIncorrectPin() {
    securePinEntryView.clearPin() // Clears the entered PIN
    Toast.makeText(this, "Incorrect PIN. Try again.", Toast.LENGTH_SHORT).show()
}

Hash, Encode, Encrypt, and Store

Always hash sensitive data and use Base64 encoding before encrypting and storing it.

Since we haven’t added any PIN security logic yet, let’s take the next step and organize it into its own class, following the Single Responsibility Principle. This way, we’ll keep things clean and put the logic in the SecurePinManager class.

import android.content.Context
import android.text.InputType
import android.widget.EditText
import androidx.security.crypto.EncryptedSharedPreferences
import androidx.security.crypto.MasterKeys
import java.security.MessageDigest
import java.util.*

class SecurePinManager(context: Context) {
    private val masterKeyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)
    private val encryptedPrefs = EncryptedSharedPreferences.create(
        "secure_prefs",
        masterKeyAlias,
        context,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun setupPinInputField(editText: EditText) {
        editText.inputType = InputType.TYPE_CLASS_NUMBER or InputType.TYPE_NUMBER_VARIATION_PASSWORD
    }

    fun savePin(pin: String) {
        val hashedPin = hashPin(pin) // Hash the PIN before saving
        encryptedPrefs.edit().putString("user_pin", hashedPin).apply()
    }

    fun verifyPin(inputPin: String): Boolean {
        val storedHashedPin = encryptedPrefs.getString("user_pin", null)
        val inputHashedPin = hashPin(inputPin) // Hash the input before comparison
        return storedHashedPin == inputHashedPin
    }

    // Hashes the PIN using SHA-256
    private fun hashPin(pin: String): String {
        val digest = MessageDigest.getInstance("SHA-256")
        val hashedBytes = digest.digest(pin.toByteArray())
        return Base64.getEncoder().encodeToString(hashedBytes) // Encode the hashed bytes in Base64
    }
}

• PIN Hashing: The PIN is now hashed using SHA-256 before saving and comparing. This adds a layer of security by ensuring the raw PIN is never stored.
• Base64 Encoding: The hashed PIN is encoded using Base64 to store it as a string in EncryptedSharedPreferences.

Prevent Sensitive Data from Being Logged

Avoid logging the entered PIN or sensitive information.

// BAD: Never log sensitive data
Log.d("PinEntry", "Entered PIN: $enteredPin") 

// GOOD: No sensitive data in logs
Log.d("PinEntry", "PIN entry attempt")

Additional Key Security Tips

• Limit Accessibility During PIN Entry: Restrict accessibility features like screen readers or magnification during PIN entry to prevent accidental exposure of sensitive information.
• Enable Biometric Authentication: Consider using biometric authentication (e.g., fingerprint, face recognition) for an extra layer of security, alongside the PIN.
• Encrypt Sensitive Data: While PINs themselves shouldn’t be stored directly, always hash sensitive data and use Base64 encoding before encrypting and storing it.
• Regularly Clear Sensitive Data: If you’re using data holders like LiveData or other similar components, ensure that sensitive data is cleared when it is no longer needed. Properly manage the lifecycle of such data to avoid unintentional retention in memory or storage.

Conclusion

Building a secure PIN entry system isn’t just about protecting data—it’s about earning user trust and safeguarding their sensitive information. With Kotlin’s secure handling features, you can create a seamless, safe experience for your users.

By following these steps, you’re not only securing their PINs but also ensuring their data is treated with the highest level of care in your financial app. Let’s keep security at the forefront and provide users the peace of mind they deserve..!

Data security is vital for financial apps. Sensitive information — whether it’s login details or payment data — needs to be protected at all times, not just when it’s stored, but also while it’s in memory. Although encryption for stored data is widely practiced, securing data in memory is sometimes underestimated. Yet, keeping data safe while it’s actively being used is equally important. In this blog, we’ll walk through best practices for handling in-memory data securely on Android. With Kotlin code, I’ll show you practical ways to protect sensitive information while it’s in use.

Why Secure In-Memory Sensitive Data Holding Matters

When your app handles sensitive information—such as user session tokens, PINs, or account numbers—it temporarily stores this data in memory during processing. If this data remains in memory longer than necessary, it becomes vulnerable to unauthorized access, particularly in environments that are rooted or debug-enabled. Attackers in these environments can potentially access memory and retrieve sensitive information from other applications. Financial apps are particularly at risk due to the highly sensitive nature of the data they handle. However, any app that stores sensitive information, such as health apps or apps handling personally identifiable information (PII), should prioritize securing in-memory data to protect user privacy and minimize the risk of exposure to attacks.

Best Practices for Securing In-Memory Data in Android

To safeguard session tokens, PINs, account numbers, and other sensitive data in memory, consider the following best practices:

1. Minimal Data Exposure
   Keep sensitive data in memory only for as long as necessary. Ensure that it is cleared promptly once it is no longer required. This minimizes the window of opportunity for attackers to access it.
2. Encryption
   Always encrypt sensitive data before storing it in memory. This ensures that even if attackers manage to access the memory, they won’t be able to interpret the data without the encryption key. Using Android’s Keystore system is highly recommended for secure encryption key management.
3. Obfuscation
   Make it more difficult for attackers to make sense of session tokens, PINs, or account numbers in memory. While obfuscation alone is not a secure measure, it adds an additional layer of protection by making the data harder to interpret if accessed.
4. Data Clearing
   Securely clear sensitive data from memory as soon as it is no longer needed. Ensure that memory is overwritten securely to prevent recovery using memory analysis tools. Consider using techniques like memcpy or similar secure memory handling functions to wipe sensitive data completely from memory.
5. Secure Memory Handling
   Consider using Android’s secure storage mechanisms like EncryptedSharedPreferences or Android Keystore to manage sensitive information securely. These tools provide a higher level of protection for storing encryption keys or sensitive data that needs to be accessed in memory.
6. Anti-Debugging and Root Detection
   Implement anti-debugging and root detection techniques to prevent attackers from using debugging tools to extract data from the app. While these techniques are not foolproof, they add an additional layer of defense.
7. Secure Coding Practices
   Avoid accidentally logging or exposing sensitive data in crash reports, logs, or other outputs. Ensure that sensitive information is handled securely throughout the app’s lifecycle.

Implementing Secure In-Memory Data Handling in Kotlin

Minimize Data Exposure

To protect sensitive data, only keep it in memory for as long as absolutely necessary. Avoid storing it in global or static variables where it might remain accessible longer than needed. Here’s how we can handle this securely in Kotlin

fun performSensitiveOperation() {
    val sensitiveData = fetchSensitiveData() // Example: fetching from secure storage
    try {
        // Use the sensitive data within a limited scope
        processSensitiveData(sensitiveData)
    } finally {
        // Clear sensitive data once it's no longer needed
        sensitiveData.clear()
    }
}

Here,

• sensitiveData is fetched and used only within the scope of the function.
• Once the operation is complete, the data is cleared, minimizing its exposure time and keeping it safe.

By ensuring sensitive data only lives in memory for the shortest time possible, you reduce the risk of unauthorized access.

Use ‘CharArray’ or ‘ByteArray’ Instead of a String

In both Java and Kotlin, String is immutable, meaning once it’s created, it cannot be modified. While this makes strings reliable for certain use cases, it can also be a security risk when dealing with sensitive data because the string cannot be cleared from memory once it’s no longer needed. On the other hand, CharArray is mutable, so we can modify its contents, making it a safer choice for sensitive information like passwords.

Here’s a quick comparison

// Avoid
val password = "SensitivePassword123"

// Better
val password = charArrayOf('S', 'e', 'n', 's', 'i', 't', 'i', 'v', 'e', 'P', 'a', 's', 's', 'w', 'o', 'r', 'd', '1', '2', '3')

Clearing CharArray After Use

Once you’re done using sensitive data stored in a CharArray, it’s important to clear it immediately to prevent it from lingering in memory. You can do this by setting all characters to \u0000 (the null character)

fun clearPassword(password: CharArray) {
    for (i in password.indices) {
        password[i] = '\u0000'
    }
}

Calling clearPassword(password) right after you’re finished using the password ensures that no sensitive data is left exposed in memory longer than necessary, reducing the risk of unauthorized access.

The same applies to ByteArray. Since ByteArray is mutable, we can modify or clear its contents after use, providing a more secure way to handle sensitive data in memory.

class SensitiveDataHandler {
    private var sensitiveData: ByteArray? = null

    // Store sensitive data securely as a ByteArray
    fun storeData(data: String) {
        sensitiveData = data.toByteArray() // Convert String data to ByteArray
    }

    // Clear the sensitive data by overwriting it with zeros
    fun clearData() {
        sensitiveData?.fill(0) // Overwrite with zeros
        sensitiveData = null // Set the reference to null
    }
}

This approach helps ensure that sensitive information is overwritten and doesn’t remain in memory, mitigating security risks if memory is compromised.

Encrypting Sensitive Data in Memory

Even with minimal exposure and proper data clearing, it’s a good practice to add an extra layer of security by encrypting sensitive data while it’s in memory. This helps protect the data in case of an attack or a breach. In Kotlin, you can use the Cipher class to easily encrypt and decrypt data on the fly.

Here’s how you can implement an encryption utility using AES-GCM for secure encryption and decryption

import javax.crypto.Cipher
import javax.crypto.KeyGenerator
import javax.crypto.SecretKey
import javax.crypto.spec.GCMParameterSpec

object MemoryEncryptionUtil {
    private const val TRANSFORMATION = "AES/GCM/NoPadding"
    private const val TAG_LENGTH_BIT = 128
    private val secretKey: SecretKey

    init {
        val keyGen = KeyGenerator.getInstance("AES")
        keyGen.init(256) // 256-bit AES encryption
        secretKey = keyGen.generateKey() // Generate a secret key
    }

    // Encrypt the data and return the initialization vector (IV) and encrypted data
    fun encrypt(data: ByteArray): Pair<ByteArray, ByteArray> {
        val cipher = Cipher.getInstance(TRANSFORMATION)
        cipher.init(Cipher.ENCRYPT_MODE, secretKey)
        val iv = cipher.iv // Get the initialization vector
        val encryptedData = cipher.doFinal(data) // Encrypt the data
        return Pair(iv, encryptedData)
    }

    // Decrypt the data using the IV and encrypted data
    fun decrypt(iv: ByteArray, data: ByteArray): ByteArray {
        val cipher = Cipher.getInstance(TRANSFORMATION)
        val spec = GCMParameterSpec(TAG_LENGTH_BIT, iv) // Specify the GCM parameter
        cipher.init(Cipher.DECRYPT_MODE, secretKey, spec) // Initialize the cipher for decryption
        return cipher.doFinal(data) // Decrypt and return the data
    }
}

• AES-GCM (Galois/Counter Mode): This encryption mode offers both confidentiality and integrity, ensuring that the encrypted data cannot be tampered with without detection.
• encrypt(): This method encrypts the given ByteArray and returns a pair consisting of the initialization vector (IV) and the encrypted data.
• decrypt(): This method takes the IV and encrypted data, decrypts it, and returns the original data in its unencrypted form.

Now, let’s see how to use this encryption utility with sensitive data

val sensitiveData = "SensitiveData".toByteArray()
val (iv, encryptedData) = MemoryEncryptionUtil.encrypt(sensitiveData)

// Decrypt the data later when needed
val decryptedData = MemoryEncryptionUtil.decrypt(iv, encryptedData)

Here,

• Sensitive data is first converted to a ByteArray.
• It is then encrypted using the encrypt() function, which returns both the IV and the encrypted data.
• When you need to access the original data, you can use the decrypt() function with the IV and encrypted data to safely decrypt it.

By implementing encryption in-memory, you provide an additional layer of protection for sensitive data, ensuring that even if an attacker gains access to the memory, the data remains unreadable.

Using Secure Storage for Persistent Data

When it comes to storing sensitive data beyond the session, it’s essential to use secure storage mechanisms to ensure that the data remains protected even after the app is closed or the device is restarted. Android’s Keystore System is specifically designed for this purpose, providing a secure place to store cryptographic keys and sensitive information like passwords and tokens.

In below code, we’ll use the Keystore to securely generate a key and then encrypt/decrypt sensitive data stored in a persistent manner.

import android.security.keystore.KeyProperties
import android.security.keystore.KeyGenParameterSpec
import java.security.KeyStore
import javax.crypto.KeyGenerator
import javax.crypto.Cipher
import javax.crypto.SecretKey
import javax.crypto.spec.GCMParameterSpec

object SecureStorageUtil {
    private const val KEY_ALIAS = "SecureKeyAlias"  // Alias for the key
    private const val TRANSFORMATION = "AES/GCM/NoPadding"  // Encryption mode and padding
    private const val TAG_LENGTH_BIT = 128  // Tag length for GCM

    // Function to retrieve or generate the encryption key
    private fun getKey(): SecretKey {
        val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }

        // Check if the key already exists
        if (!keyStore.containsAlias(KEY_ALIAS)) {
            val keyGen = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
            val spec = KeyGenParameterSpec.Builder(KEY_ALIAS,
                KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT)
                .setBlockModes(KeyProperties.BLOCK_MODE_GCM)  // Set GCM block mode
                .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)  // No padding
                .build()
            keyGen.init(spec)
            keyGen.generateKey()  // Generate the key and store it securely
        }

        // Return the secret key from the keystore
        return (keyStore.getEntry(KEY_ALIAS, null) as KeyStore.SecretKeyEntry).secretKey
    }

    // Function to encrypt data using the Keystore key
    fun encrypt(data: ByteArray): Pair<ByteArray, ByteArray> {
        val cipher = Cipher.getInstance(TRANSFORMATION)
        cipher.init(Cipher.ENCRYPT_MODE, getKey())  // Initialize cipher with encryption key
        val iv = cipher.iv  // Get the initialization vector (IV)
        val encryptedData = cipher.doFinal(data)  // Encrypt the data
        return Pair(iv, encryptedData)  // Return both IV and encrypted data
    }

    // Function to decrypt data using the Keystore key
    fun decrypt(iv: ByteArray, encryptedData: ByteArray): ByteArray {
        val cipher = Cipher.getInstance(TRANSFORMATION)
        cipher.init(Cipher.DECRYPT_MODE, getKey(), GCMParameterSpec(TAG_LENGTH_BIT, iv))  // Initialize cipher for decryption
        return cipher.doFinal(encryptedData)  // Decrypt and return the data
    }
}

• Key Generation: If the key doesn’t already exist in the Keystore, it is generated using KeyGenerator with the AES algorithm and stored in the AndroidKeyStore. This ensures the key never leaves the secure hardware and is not accessible by unauthorized parties.
• AES-GCM Encryption: We use AES in Galois/Counter Mode (GCM), which provides both encryption and integrity protection. The Cipher class is used to perform encryption and decryption operations with the key stored in the Keystore.

Data Encryption & Decryption

• encrypt(): Encrypts the input data and returns both the initialization vector (IV) and encrypted data. The IV is crucial for decrypting the data later.
• decrypt(): Uses the stored key to decrypt the data by passing the IV and encrypted data.

Here’s how we can use SecureStorageUtil to securely store and retrieve encrypted data, again, similar to the encryption utility mentioned above.

val sensitiveData = "SensitiveData".toByteArray()

// Encrypt the data
val (iv, encryptedData) = SecureStorageUtil.encrypt(sensitiveData)

// Decrypt the data later when needed
val decryptedData = SecureStorageUtil.decrypt(iv, encryptedData)

But, why do we use Keystore?

The Android Keystore System ensures that the cryptographic keys are stored securely in hardware-backed storage (if available), making them less vulnerable to attacks such as device rooting or debugging. By using Keystore for key management, you reduce the risk of exposing sensitive data, even if the app is compromised.

This approach helps ensure that sensitive data is encrypted both at rest (when stored) and in transit (while being processed), providing an additional layer of security for your financial app’s sensitive information.

Conclusion

By implementing these practices, you can significantly mitigate the risk of sensitive data being exposed in memory:

• Minimize data exposure by limiting its time in memory.
• Use mutable types like CharArray or ByteArray and clear them after use.
• Encrypt sensitive data while in memory.
• Store persistent data securely using Android’s Keystore system.

These measures ensure that even if an attacker gains access to memory or persistent storage, they won’t be able to easily retrieve sensitive information.

Protecting sensitive data in financial apps is essential to prevent security breaches that could put user information, app configurations, and financial transactions at risk. In this blog, I’ll walk you through how to secure configuration data in financial apps. We’ll begin by looking at common vulnerabilities, then move on to practical solutions like encryption and secure storage practices. Along the way, I’ll break things down step by step to help you apply these strategies with ease. Let’s dive in and make your financial app more secure!

Why Configuration Data Protection Needed?

Configuration data is essential in financial apps as it often contains API keys, URLs, and settings that control how the app behaves. In financial apps, this data is particularly sensitive. If it’s not properly secured, attackers could exploit vulnerabilities, bypass authentication, steal financial data, or even manipulate transactions.

Core Techniques to Protect Configuration Data

Here are a few core techniques to keep your configuration data secure:

1. Using Encrypted SharedPreferences for Sensitive Data
2. Encrypting API Keys and Tokens
3. Using Android Keystore for Secure Key Management
4. Network Security Configuration for Secure Data Transmission

Let’s dive into each of these, starting with Encrypted SharedPreferences.

Using Encrypted SharedPreferences for Sensitive Data

SharedPreferences is commonly used in Android to store small pieces of data, like user settings or app preferences. However, the downside is that standard SharedPreferences stores data in plain text, which can easily be accessed if the device is compromised. This is a significant security risk, especially when dealing with sensitive information like API keys.

To secure sensitive data, we can use EncryptedSharedPreferences. It encrypts the data, ensuring that even if someone gains access to the storage, they won’t be able to read the sensitive information.

Here’s how you can use EncryptedSharedPreferences:

import androidx.security.crypto.EncryptedSharedPreferences
import androidx.security.crypto.MasterKeys

fun getSecureSharedPreferences(context: Context): SharedPreferences {
    val masterKeyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)

    return EncryptedSharedPreferences.create(
        "secure_preferences", // Name of the preferences file
        masterKeyAlias, // The master key for encryption
        context,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )
}

fun saveConfigData(context: Context, apiKey: String) {
    val sharedPreferences = getSecureSharedPreferences(context)
    with(sharedPreferences.edit()) {
        putString("api_key", apiKey)
        apply() // Save the data securely
    }
}

fun getConfigData(context: Context): String? {
    val sharedPreferences = getSecureSharedPreferences(context)
    return sharedPreferences.getString("api_key", null) // Retrieve the secure data
}

Here,

• MasterKeys.getOrCreate() creates a master key using AES-256 encryption. This key is used to encrypt the data.
• EncryptedSharedPreferences.create() initializes the EncryptedSharedPreferences instance with the specified encryption schemes for both the keys and values.
• putString() securely saves sensitive data like API keys, while getString() retrieves the encrypted value.

By using EncryptedSharedPreferences, we ensure that even if someone gains unauthorized access to the device’s storage, the data remains encrypted and safe. This is a simple yet powerful way to protect sensitive configuration data in your financial app.

Encrypting API Keys and Tokens

Hardcoding API keys and tokens directly into your app’s code can create serious security vulnerabilities. If someone decompiles your app or gains unauthorized access, these sensitive credentials could be exposed. Instead, it’s safer to store them in an encrypted format and decrypt them only when needed during runtime.

Here’s how you can use AES encryption in Kotlin to securely handle your API keys and tokens.

import javax.crypto.Cipher
import javax.crypto.KeyGenerator
import javax.crypto.SecretKey
import javax.crypto.spec.GCMParameterSpec
import android.util.Base64

// Encrypting a string with AES
fun encryptData(plainText: String, secretKey: SecretKey): String {
    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    cipher.init(Cipher.ENCRYPT_MODE, secretKey)
    val iv = cipher.iv
    val encryptedData = cipher.doFinal(plainText.toByteArray())
    val ivAndEncryptedData = iv + encryptedData
    return Base64.encodeToString(ivAndEncryptedData, Base64.DEFAULT)
}

// Decrypting the encrypted string
fun decryptData(encryptedText: String, secretKey: SecretKey): String {
    val ivAndEncryptedData = Base64.decode(encryptedText, Base64.DEFAULT)
    val iv = ivAndEncryptedData.sliceArray(0 until 12) // Extract the 12-byte IV
    val encryptedData = ivAndEncryptedData.sliceArray(12 until ivAndEncryptedData.size)
    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    val gcmParameterSpec = GCMParameterSpec(128, iv) // 128-bit authentication tag length
    cipher.init(Cipher.DECRYPT_MODE, secretKey, gcmParameterSpec)
    val decryptedData = cipher.doFinal(encryptedData)
    return String(decryptedData)
}

// Generate Secret Key for AES
fun generateSecretKey(): SecretKey {
    val keyGenerator = KeyGenerator.getInstance("AES")
    keyGenerator.init(256) // AES 256-bit encryption
    return keyGenerator.generateKey()
}

• AES/GCM/NoPadding: This mode provides strong encryption and also ensures no unnecessary padding is added, keeping the data size as small as possible.
• Initialization Vector (IV): The IV is crucial for ensuring that even if the same data is encrypted multiple times, the output will differ. It’s stored alongside the encrypted data and is required for decryption.
• generateSecretKey(): This method creates a 256-bit AES key, which can be used for both encryption and decryption. To further enhance security, you can store this key in the Android Keystore.

By using AES encryption to handle your API keys and tokens, you’re adding an extra layer of security to prevent unauthorized access to your financial app’s sensitive data. This approach ensures that your sensitive information remains secure, even if the device is compromised.

Btw, I know you might be wondering about one term. Any guesses..? Without further delay, let’s take a look!

What is an IV (Initialization Vector)?

An Initialization Vector (IV) is a random value used in cryptographic algorithms, such as AES, to ensure that each encryption operation produces unique results — even when encrypting the same data multiple times with the same key.

Why is IV Important?

• Prevents Repeated Patterns:
  Without an IV, encrypting the same data with the same key would always result in the same ciphertext. This predictability is a security risk. The IV ensures that even when encrypting identical data, the output (ciphertext) will be different each time, making it harder for attackers to detect patterns or deduce information.
• Enhances Security:
  In encryption modes like AES-CBC (Cipher Block Chaining) or AES-GCM (Galois/Counter Mode), the IV plays a crucial role by adding randomness to the encryption process. This added randomness strengthens the encryption, making it more resistant to attacks.
• Must Be Unique:
  The IV doesn’t need to be kept secret, but it must be unique for each encryption operation. Reusing the same IV with the same key for different data introduces vulnerabilities. When an IV is reused, attackers may be able to spot patterns or exploit weaknesses in the encryption.

How Does the IV Work?

• During Encryption:
  The IV is combined with the plaintext and encryption key to create the ciphertext. Its role is to introduce randomness, ensuring that even identical plaintexts will produce different ciphertexts when encrypted.
• During Decryption:
  To decrypt the data properly, the same IV used during encryption must be provided. It’s typically sent alongside the ciphertext, ensuring the receiver can use it during decryption to recover the original data.

Storing and Transmitting the IV

The IV itself doesn’t need to be kept secret, but it must be made available to the receiver. Usually, it’s transmitted along with the encrypted data, either as a prefix or in a predefined format. This ensures that the IV can be used during decryption. However, even though the IV isn’t secret, it still must be securely transmitted to ensure proper decryption.

Let’s get back to our discussion on App Configuration Data Protection and see how we can use Android Keystore for secure key management.

Using Android Keystore for Secure Key Management

Storing encryption keys directly in the app can leave them vulnerable to attacks. To avoid this, we can use the Android Keystore system, which securely stores keys either in hardware or a secure enclave, ensuring that only the app has access to them. This adds a significant layer of protection, especially for sensitive data.

Here’s how you can generate and securely manage keys using the Keystore:

import android.security.keystore.KeyGenParameterSpec
import android.security.keystore.KeyProperties
import java.security.KeyStore
import javax.crypto.KeyGenerator
import javax.crypto.SecretKey

// Generate and store a key in Android Keystore
fun createKey() {
    val keyGenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
    val keyGenParameterSpec = KeyGenParameterSpec.Builder(
        "SecureKeyAlias",
        KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
    ).setBlockModes(KeyProperties.BLOCK_MODE_GCM)
     .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
     .build()
    keyGenerator.init(keyGenParameterSpec)
    keyGenerator.generateKey()
}

// Retrieve the secret key from Keystore
fun getSecretKey(): SecretKey? {
    val keyStore = KeyStore.getInstance("AndroidKeyStore")
    keyStore.load(null)
    return keyStore.getKey("SecureKeyAlias", null) as SecretKey?
}

• KeyGenParameterSpec.Builder: This part sets the encryption requirements, such as the encryption block mode and padding. In this case, we’re using AES with GCM mode, which is both secure and efficient.
• createKey(): This function creates a new AES encryption key and securely stores it in the Keystore with the alias SecureKeyAlias. The key is only accessible to the app, making it safe from potential leaks.
• getSecretKey(): This function retrieves the stored key from the Keystore when needed for encryption or decryption. The key is never exposed in the code, adding an extra layer of security.

By using the Android Keystore, we avoid the risk of exposing sensitive keys within the app, ensuring a higher level of security for encryption operations.

Network Security Configuration for Secure Data Transmission

In financial apps, securely transmitting sensitive data over HTTPS is critical to prevent man-in-the-middle attacks. If not properly configured, cleartext traffic (HTTP) can expose this data to unauthorized access. To ensure your app uses HTTPS and blocks any unencrypted traffic, you can define network security policies using a configuration file.

Here’s how to enforce HTTPS using a network security configuration in your app

Create a network security configuration file (network_security_config.xml) in the res/xml folder:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">yourapi.com</domain>
    </domain-config>
</network-security-config>

Link the configuration in your AndroidManifest.xml:

<application
    android:networkSecurityConfig="@xml/network_security_config"
    ... >
</application>

• cleartextTrafficPermitted="false": This setting ensures that the app only allows encrypted HTTPS traffic and blocks any HTTP (cleartext) traffic, preventing sensitive data from being exposed.
• <domain> tag: You specify trusted domains (like yourapi.com) that the security settings apply to, including all of its subdomains (by setting includeSubdomains="true").

By adding this configuration, you’re ensuring that your financial app’s data transmissions remain secure, guarding against potential security threats.

Conclusion 

Securing app configuration data in financial apps is essential for protecting sensitive user information and maintaining trust. By implementing practices like using EncryptedSharedPreferences, encrypting sensitive values, storing keys in the Android Keystore, and enforcing HTTPS, you can significantly reduce the risk of data breaches and vulnerabilities.

These steps will help ensure that your financial Android app handles sensitive data securely, giving users the peace of mind they need when using your app.

When building financial apps, security should always be a top priority. Sensitive information like banking credentials, personal details, and financial records must be protected at all costs. One often-overlooked security measure is disabling app data backups. While Android’s automatic cloud backup feature is convenient, it can expose sensitive data if not managed properly. In this guide, we’ll walk through the steps to disable app data backup in Android apps, ensuring that user data remains secure.

Why Disable App Data Backup in Financial Apps?

While app data backup can be a convenient feature for many apps, it poses risks for apps that handle sensitive financial data. Here’s why it’s crucial to disable it:

• Protecting Sensitive Data: If a device is compromised or when users switch to a new device, any backed-up data could be exposed during restoration, which is a major security concern.
• Ensuring Compliance: Many financial institutions have strict data security requirements, and allowing data to be backed up to external storage might violate these regulations.
• Reducing Risk: Disabling backups prevents data from being stored on potentially less secure platforms or devices, keeping it safe from unauthorized access.

Before disabling the backup, let’s first take a moment to see which files are usually being backed up.

What Gets Backed Up

By default, Auto Backup includes files from most directories assigned to your app by the system, such as:

• Shared Preferences Files
• Internal Storage Files: Files saved to your app’s internal storage and accessed via getFilesDir() or getDir(String, int)
• Database Files: Files in the directory returned by getDatabasePath(String), including those created using SQLiteOpenHelper
• External Storage Files: Files located in the directory returned by getExternalFilesDir(String)

Auto Backup doesn’t include files stored in certain directories, such as:

• Cache Directory: Files saved in getCacheDir(), getCodeCacheDir(), and getNoBackupFilesDir()
  These files are temporary and are intentionally excluded from backup to avoid unnecessary storage and syncing.

You can customize the backup process by specifying which files should be included or excluded from Auto Backup, giving you greater control over the data your app manages.

How Disabling App Data Backup Works in Android

By default, Android automatically backs up an app’s data to Google Drive, including SharedPreferences, files, and other persistent data. This process is controlled by the android:allowBackup attribute in the app’s AndroidManifest.xml. By setting this attribute to false, the app ensures its data is not backed up, which is essential for securing financial apps and other apps that handle sensitive information.

<application
    android:name=".FinancialApp"
    android:allowBackup="false"
    android:fullBackupContent="false"
    ... >
    <!-- other configurations -->
</application>

allowBackup="false":

• This attribute prevents Android from automatically backing up the app’s data to Google Drive or any other backup service. This includes both user-initiated and system-initiated backups. Setting allowBackup="false" effectively disables the Android backup mechanism for the app, reducing the risk of unauthorized access to app data through backups.
• Important Note: While this setting prevents automatic backups through Android’s system, it does not guarantee complete protection. Devices with root access or custom ROMs can bypass this setting and potentially access app data or perform backups using alternative methods.

fullBackupContent="false":

• This attribute ensures that the app’s data is excluded from full device backups, regardless of the allowBackup setting. When set to false, it prevents the app’s data from being included in any full-device backup (such as Google’s full-device backup feature) even if allowBackup is set to true.
• Important Note: This attribute prevents the app’s data from being included in standard full backups, but it does not protect against all possible data extraction methods. Devices with root access or custom ROMs may still be able to access the app’s data through other means, such as direct file system access.

While both allowBackup="false" and fullBackupContent="false" significantly reduce the chances of unauthorized backups and data exposure, they do not provide 100% protection, especially on rooted or compromised devices. That’s why, in financial apps, we check if the device is rooted and implement additional tampering checks to enhance security.

Securing Sensitive Data Locally

Disabling backups is only part of the equation in securing sensitive data. It’s also crucial to protect locally stored information. Jetpack’s Security library provides tools like EncryptedSharedPreferences and EncryptedFile in Kotlin, which ensure that data stored on the device remains encrypted. These components integrate seamlessly with Android’s architecture and provide strong encryption, making them excellent choices for securely handling sensitive data in financial or personal apps.

Using EncryptedSharedPreferences

import android.content.Context
import androidx.security.crypto.EncryptedSharedPreferences
import androidx.security.crypto.MasterKeys

fun getEncryptedSharedPreferences(context: Context): SharedPreferences {
    val masterKeyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)
    return EncryptedSharedPreferences.create(
        "financial_prefs",
        masterKeyAlias,
        context,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )
}

Here,

• MasterKeys: Creates or retrieves a master key that is used to encrypt the shared preferences.
• EncryptedSharedPreferences: Securely stores shared preferences with AES encryption, which is suitable for sensitive data.
• PrefKeyEncryptionScheme & PrefValueEncryptionScheme: These schemes ensure both keys and values in SharedPreferences are encrypted, providing additional security.

Securely Storing Files with EncryptedFile

Sometimes, an app may need to store files, such as transaction records or receipts. Using EncryptedFile can help ensure these files are securely stored.

import androidx.security.crypto.EncryptedFile
import androidx.security.crypto.MasterKeys
import java.io.File

fun getEncryptedFile(context: Context, fileName: String): EncryptedFile {
    val masterKeyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)
    val file = File(context.filesDir, fileName)

    return EncryptedFile.Builder(
        file,
        context,
        masterKeyAlias,
        EncryptedFile.FileEncryptionScheme.AES256_GCM_HKDF_4KB
    ).build()
}

fun writeToEncryptedFile(context: Context, data: String) {
    val encryptedFile = getEncryptedFile(context, "sensitive_data.txt")
    encryptedFile.openFileOutput().use { output ->
        output.write(data.toByteArray())
    }
}

• EncryptedFile: Provides AES256_GCM encryption to ensure that files are securely stored on disk.
• FileEncryptionScheme: Specifies the encryption scheme to use for file security, which includes AES encryption with a secure HKDF key derivation function.

Additional Security Considerations

• Use ProGuard: Obfuscate your app’s code to make it much harder for attackers to reverse-engineer.
• Implement Strong User Authentication: For accessing sensitive areas of the app, use secure authentication methods like biometrics or PINs.
• Clear Sensitive Data on Logout: Ensure that all stored sensitive data is cleared when the user logs out or exits.

Here’s a quick example of a function to clear sensitive data from EncryptedSharedPreferences:

fun clearSensitiveData(context: Context) {
    val encryptedPrefs = getEncryptedSharedPreferences(context)
    encryptedPrefs.edit().clear().apply()
}

This function retrieves the EncryptedSharedPreferences instance and clears all saved data, ensuring that no sensitive information remains stored in the app.

Testing Backup Disabling and Data Security

To ensure everything is working as expected, it’s crucial to test that app data isn’t backed up and that sensitive data remains secure:

• Backup Testing: After setting up the backup restriction, install the app, add some data, and try to back it up through device settings or ADB. Check to confirm that none of the app’s data is backed up.
• Encryption Verification: Attempt to access shared preferences or files outside the app’s context, such as by using a file manager or rooted device. This helps verify that sensitive data remains encrypted and unreadable, confirming the security setup is effective.

Testing these areas ensures that data protection features are robust and that user data remains secure, especially for apps managing sensitive information.

Conclusion 

Disabling app data backup in Android apps, especially financial ones, is essential for protecting user data and complying with strict security requirements. By making a few adjustments in the AndroidManifest and following secure data storage practices, you can help ensure that your app’s sensitive data remains safe from unauthorized backups and access. Implementing these steps and following security best practices will help you build a more secure financial app that safeguards your users’ valuable data.

In financial Android apps, setting up local session timeouts is essential to prevent unauthorized access if a user leaves the app unattended. With a session timeout, the app automatically logs the user out after a certain period of inactivity, adding a layer of security to protect sensitive data.

In this blog, I’ll walk you through:

• What a local session timeout is
• Why session timeouts are crucial for financial apps
• How to implement a session timeout in Kotlin with step-by-step code
• Best practices for managing session timeouts effectively

Let’s dive into how you can secure your app and enhance user trust by setting up session timeouts the right way.

What is a Local Session Timeout?

A local session timeout is a security feature that helps keep user data safe by tracking inactivity. If a user hasn’t interacted with the app for a set amount of time, the app will automatically log them out. This feature is especially important in financial apps, where protecting sensitive information is a top priority.

Why Local Session Timeout is Important for Financial Apps

In financial apps, leaving a session open can be a serious security risk. If someone else picks up the user’s phone, they could access the app and potentially perform unauthorized actions. By adding a session timeout, we:

• Reduce the risk of unauthorized access,
• Safeguard sensitive financial data, and
• Ensure compliance with security standards in the financial industry.

How to Set Up a Local Session Timeout

Here’s how to add a local session timeout feature to an Android app using Kotlin. We’ll take it step-by-step:

1. Define the Inactivity Timeout Duration — Decide how long the app should remain active without user interaction.
2. Track User Activity — Monitor interactions like touches, scrolls, or button presses to keep track of activity.
3. Reset the Timer — Each time the user interacts with the app, reset the timer to give them more active time.
4. Handle the Timeout — If no activity is detected within the specified time, log the user out automatically.

Step-by-Step Implementation in Kotlin

Step 1: Set Up Constants

First, let’s define a constant for our timeout duration. For example, we might want a timeout of 5 minutes.

const val TIMEOUT_DURATION = 5 * 60 * 1000L // 5 minutes in milliseconds

Step 2: Create a SessionManager Class

Next, let’s create a SessionManager class to handle the session tracking and timeout. This class will manage a timer that resets every time the user interacts with the app.

class SessionManager(private val context: Context) {

    private var timer: CountDownTimer? = null

    // Start or restart the inactivity timer
    fun startSessionTimeout() {
        timer?.cancel() // cancel any existing timer
        timer = object : CountDownTimer(TIMEOUT_DURATION, 1000L) {
            override fun onTick(millisUntilFinished: Long) {
                // Optionally, add logging or other feedback here
            }

            override fun onFinish() {
                onSessionTimeout()
            }
        }.start()
    }

    // Reset the timer on user interaction
    fun resetSessionTimeout() {
        startSessionTimeout()
    }

    // Handle session timeout (e.g., log the user out)
    private fun onSessionTimeout() {
        // Example action: Redirect to login screen
        context.startActivity(Intent(context, LoginActivity::class.java).apply {
            flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK
        })
    }

    // Cancel the timer when the session ends
    fun endSession() {
        timer?.cancel()
    }
}

• startSessionTimeout: Starts or restarts a countdown timer. If there’s no activity, onFinish() calls onSessionTimeout().
• resetSessionTimeout: Resets the timer whenever the user interacts with the app.
• onSessionTimeout: This function defines what happens when the timer expires. Here, we’re redirecting the user to the login screen.
• endSession: Cancels the timer when the session ends, helping save resources.

Step 3: Integrate Session Timeout in the Main Activity

In your main activity, you’ll initialize SessionManager and handle user interactions to keep the timer updated.

class MainActivity : AppCompatActivity() {

    private lateinit var sessionManager: SessionManager

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        sessionManager = SessionManager(this)

        // Start the session timer when the activity is created
        sessionManager.startSessionTimeout()
    }

    override fun onUserInteraction() {
        super.onUserInteraction()
        // Reset the session timeout on any user interaction
        sessionManager.resetSessionTimeout()
    }

    override fun onDestroy() {
        super.onDestroy()
        // End the session when the activity is destroyed
        sessionManager.endSession()
    }
}

• onUserInteraction: This built-in method is called whenever the user interacts with the app (touch, scroll, etc.). We’re using it to reset the session timeout.
• onDestroy: Stops the timer if the activity is destroyed, which helps save resources.

Step 4: Add Login Handling (Optional)

Redirecting the user to the login screen upon timeout adds an extra layer of protection for sensitive data. Assuming you have a LoginActivity set up, the SessionManager class will send users there if their session times out.

Best Practices for Session Timeout in Financial Apps

• Choose a Practical Timeout Duration: For financial apps, a timeout of 5 to 10 minutes of inactivity is generally a good choice. It strikes the right balance between keeping data secure and not being too disruptive for the user.
• Notify the User Before Logging Out: Many apps show a quick warning dialog just before logging out. This gives users a chance to stay logged in by interacting with the app, making the experience smoother and reducing unexpected logouts.
• Handle Background State Changes Carefully: If the user switches to another app or the app moves to the background, consider starting the timeout timer or even logging out immediately. This reduces the risk of leaving sensitive data open if the app isn’t actively being used.

Conclusion

Implementing session timeouts in financial apps is essential for protecting user data. I’ve shared how using Kotlin and Android’s CountDownTimer makes it simple to set up a reliable timeout system. By choosing a practical timeout duration, notifying users before logout, and handling background state changes, we can ensure that our apps are both secure and user-friendly.

As developers, it’s our job to safeguard sensitive information while making sure the app remains intuitive. With these steps in place, you’ll be able to create a financial app that balances both security and a smooth user experience. Keep iterating and refining—this approach will help you build a stronger, safer app over time.