Store Secrets with Android Keystore: Encrypt Data, Do Not Store Passwords as Keys

Prefer a revocable credential over a saved password

For an account-backed app, use the authentication provider's supported session or token mechanism where possible. A long-lived user password stored locally increases the consequences of a mistake and complicates revocation.

If offline access genuinely needs a local secret, define its lifetime, recovery behavior and threat model. Encryption protects a particular boundary; it does not stop malicious code already executing with the app's privileges from abusing authorized operations. Android Keystore.

Separate key, ciphertext and metadata

A defensible encrypted record includes the ciphertext, the algorithm/version information needed to interpret it and a unique IV or nonce where required. The encryption key should not be stored beside the ciphertext as a hardcoded string.

For AES-GCM, never reuse the same IV with the same key. Let the cryptographic implementation generate an appropriate fresh IV during encryption and preserve it with the ciphertext. Authenticate the data and treat a failed authentication check as a real failure, not a reason to return partial plaintext. Cryptography guidance.

Plan failure states explicitly

A try/catch that replaces the encrypted record with plaintext makes the error path the weakest security path.

Keep secrets out of secondary surfaces

Do not log plaintext, place it in crash-report custom attributes or copy it into clipboard-based diagnostics. Review backups, screenshots, exported files and analytics parameters. Securing one preferences file is incomplete if the same credential appears in a support log.

Android's security practices help frame these adjacent channels. Use a test account and inspect actual files and reports during validation.

Test recovery as well as success

Exercise first use, process restart, sign-out, reinstall, restore and a deliberately corrupted encrypted record. Confirm that each path produces a safe, understandable outcome.

APKLint's privacy and static-code tools can highlight suspicious APIs or hardcoded values, but they cannot prove that your runtime key lifecycle, IV handling or authentication-bound recovery logic is correct. That requires implementation review and device tests.