Key difference between shared_preferences and flutter_secure_storage for tokens

WHAT THIS TESTS: This question evaluates whether you understand data-at-rest security on mobile and can name the actual platform primitives that protect secrets. Interviewers want to hear that you know shared_preferences is unencrypted by design and that flutter_secure_storage binds encryption keys to hardware-backed or OS-level trust boundaries. It also checks if you understand the threat model of rooted devices, backups, and sandbox escapes.

A GOOD ANSWER COVERS: First, state that shared_preferences persists data as plain text. On Android it writes to an XML file in the app sandbox, and on iOS it uses NSUserDefaults backed by a plist, neither of which encrypts values. Second, explain that flutter_secure_storage encrypts before writing. On iOS and macOS it stores values in the Keychain with configurable accessibility levels such as afterFirstUnlock or whenUnlocked. On Android it uses the Android Keystore to generate RSA OAEP keys that wrap AES-GCM storage keys, ensuring the raw encryption key never leaves the secure hardware or TEE when available. Third, mention the backup risk: shared_preferences data is included in standard Android Auto Backup and iTunes backups unless explicitly excluded, while secure storage defaults exclude or encrypt backup content. Fourth, note that flutter_secure_storage supports optional biometric binding on Android API 23 plus and iOS, adding an additional user-authentication gate.

COMMON WRONG ANSWERS: A major red flag is claiming shared_preferences is fine because the app sandbox keeps other apps out. Another is suggesting that ProGuard, R8, or Dart code obfuscation protects stored tokens, since obfuscation does nothing for data at rest. Some candidates confuse shared_preferences with EncryptedSharedPreferences or think flutter_secure_storage is just a wrapper around shared_preferences with a password. Avoid saying HTTPS protects the token after it is stored locally.

LIKELY FOLLOW-UPS: The interviewer may ask how you would rotate keys if a user moves to a new device, or how accessibility settings on iOS Keychain affect background refresh behavior. They might also ask what happens on rooted Android devices or how to handle the web platform where flutter_secure_storage requires HTTPS. Another common follow-up is whether you should store the refresh token at all, or if a token vault or OAuth PKCE flow is preferable.

ONE CONCRETE EXAMPLE: Suppose you store a JWT refresh token. With shared_preferences, an attacker with physical access could adb backup the app data and read the XML containing the token in seconds. With flutter_secure_storage, the same backup would contain only ciphertext, and the AES-GCM key required to decrypt it is stored in Android Keystore hardware that does not export key material. On iOS, the token resides in Keychain items that respect the device passcode and are not exposed through standard plist extraction.

Source: pub.dev flutter_secure_storage package documentation.