Banking App Security: Why SharedPreferences is a Liability

In mobile development,

(Android) and

(iOS) are the “go-to” tools for saving simple settings like a user’s theme preference or a “Remember Me” toggle. However, using these for session tokens or authentication secrets in a banking application is a critical security flaw.

Even on a non-rooted device, this practice exposes users to significant risks and fails to meet modern financial security standards.

The Risk: The “Backup” Backdoor

The primary risk of storing a session token in

on a non-rooted device is Unauthorized Data Extraction via Backups.

How the Attack Works

By default, Android’s backup system (via

or cloud sync) includes the application’s private data folder, where

files are stored as plain-text XML.

1. Physical Access: If an attacker gets physical access to an unlocked device for just a few minutes, they can trigger a backup to an external machine.
2. The Extraction: Because
   SharedPreferences

   is not encrypted by the OS, the attacker can extract the

   shared_prefs/*.xml

   file.

3. Session Hijacking: The attacker now has a valid, active session token. They can “replay” this token from their own device or a browser to bypass the login screen and gain full access to the victim’s bank account without ever needing the password or MFA.

The “Malware” Pivot

While Android isolates apps through “sandboxing,” vulnerabilities in the OS or other high-privilege apps can sometimes allow a malicious app to bypass these boundaries. If a token is stored in plain text, any process that manages to escalate privileges can scrape the token instantly.

The Modern Standard: Hardware-Backed Security

To meet modern security standards (like OWASP MASVS), sensitive data must be stored in a location that provides encryption at rest and hardware-level isolation.

The Secure Alternative: Android Keystore & EncryptedSharedPreferences

The correct approach for a banking application is to use the Android Keystore System in conjunction with EncryptedSharedPreferences.

1. Android Keystore (The Vault)

The Keystore does not store the token itself; it stores the cryptographic keys used to encrypt the token. These keys are stored in a Trusted Execution Environment (TEE) or a Secure Element (SE)—dedicated hardware on the phone that is physically isolated from the main Android OS. Even if the OS is compromised, the keys cannot be extracted.

2. EncryptedSharedPreferences (The Wrapper)

This is a part of the Jetpack Security library. It acts as a wrapper around the standard SharedPreferences but adds two critical layers:

• Value Encryption: Every value (like your session token) is encrypted using keys managed by the Keystore.
• Key Encryption: The keys themselves are protected, ensuring that even if an attacker steals the XML file, they see only encrypted gibberish.

Why This Works

If an attacker triggers a backup of an app using

, they will successfully steal the XML file, but they cannot steal the keys from the hardware-backed Keystore. Without the keys, the stolen session token is mathematically impossible to decrypt, rendering the backup attack useless.

Conclusion

For a banking application, “it works” is not enough. You must assume the device might be physically accessible to an attacker or that the software environment might be compromised.

By moving session tokens from standard

to hardware-backed EncryptedSharedPreferences, you ensure that the “keys to the kingdom” never leave the device’s physical security module.

In financial software, if the hardware isn’t protecting the secret, the secret isn’t protected.

Banking App Security: Why SharedPreferences is a Liability by Psyops Prime is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.