Context

Applications often store both low-risk settings and high-risk secrets. Interviewers want to see whether you can distinguish convenience data from credentials and choose the right storage approach.

Core question

Explain how you would handle secure storage of user preferences versus truly sensitive data such as access tokens, refresh tokens, API keys, or passwords.

Address these points:

1. How do you classify data by sensitivity and risk?
2. What storage choices are appropriate for preferences versus secrets?
3. What protections should exist around encryption, key management, access control, and rotation?

Scope guidance

You do not need to design a full production security platform. Focus on practical engineering decisions, clear threat modeling, and the trade-offs between usability, performance, and security. A strong answer should distinguish harmless settings from secrets, explain why “encrypt everything” is not always the full answer, and describe how platform-provided secure storage changes the design.

Data Classification

Not all stored data has the same risk. Theme settings, language choice, and UI layout are usually low sensitivity, while tokens, credentials, and private keys are high sensitivity because compromise can grant account or system access.

def classify_key(key):
    secret_keys = {'access_token', 'refresh_token', 'api_key', 'password'}
    return 'secret' if key in secret_keys else 'preference'

Secure Storage vs Regular Storage

Low-risk preferences can often be stored in regular local storage, files, or app settings because exposure has limited impact. Secrets should be stored in OS-backed secure storage such as Keychain, Keystore, or a server-side secret manager, where encryption keys are protected outside normal app memory and file paths.

Encryption and Key Management

Encryption only helps if the key is protected separately from the encrypted data. Storing ciphertext and the decryption key in the same place gives little real protection, so secure designs rely on hardware-backed or managed key stores.

encrypted_value = encrypt(secret, key_from_secure_store)

Least Privilege and Access Control

Only the components that truly need a secret should be able to read it. Limiting access reduces blast radius if one part of the application is compromised and makes auditing easier.

Rotation and Expiration

Sensitive tokens and credentials should be short-lived when possible and rotated when exposed, expired, or no longer needed. Preferences usually do not require rotation, but secrets should have lifecycle management built in from the start.