Data Storage Security Interview Questions
SECURITY › Security
Walk me through how you'd decide what actually needs to be encrypted at rest in an app versus what's fine in plain SharedPreferences.
What a strong answer covers: A strong answer draws the line at sensitivity and blast radius: auth tokens, passwords, PII, payment details, and anything granting account access or violating privacy on a rooted or stolen device must be Keystore-backed or encrypted, while purely cosmetic app state like a theme preference or onboarding-seen flag is fine in plain SharedPreferences since encrypting it adds overhead with no real security benefit. Should also flag that plaintext SharedPreferences is readable by anyone with root or a backup extraction, so the decision hinges on what a device compromise or lost-phone scenario would expose.
When would you reach for a StrongBox-backed key over a TEE-backed key, given the trade-offs? What's a scenario where insisting on StrongBox actually hurts you?
What a strong answer covers: StrongBox is a separate dedicated secure element, more isolated from the main CPU and OS and resistant to a wider class of physical and side-channel attacks, but it's slower and not available on all devices, so requiring it unconditionally locks out part of the device fleet without a fallback. A strong answer notes that insisting on StrongBox for something like everyday token storage on a mid-range-heavy user base means either building fallback compatibility logic or breaking the feature for those users, when a TEE-backed key is already a strong, near-universal baseline for most threat models.
A security reviewer flags that your app's Keystore-backed encryption doesn't protect against a rooted device with a live debugger attached to your process. How do you respond, given the key material never leaves hardware?
What a strong answer covers: A strong answer is honest about the limit: Keystore protects key material from extraction since it never leaves hardware, but on a rooted device with a debugger attached, an attacker can still invoke the app's own decrypt operations while it runs and read whatever plaintext the app produces, so they get the decrypted output on demand without ever getting the key. It should frame Keystore as raising the bar, no bulk key exfiltration, no offline brute force, rather than making data safe on a fully compromised device, and mention layers like root detection or minimizing what's decrypted into memory at once as reducing, not eliminating, that exposure.