Key difference between shared_preferences and flutter_secure_storage for tokens
Tests at-rest encryption: shared_preferences stores plain text XML/plist, while secure storage uses iOS Keychain and Keystore with RSA OAEP plus AES-GCM. Answers cite backup risks and hardware keys. Red flag: calling prefs safe or relying on obfuscation.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
Why does storing a JWT refresh token in flutter_secure_storage provide stronger protection than using shared_preferences?
- a.HTTPS ensures the token is encrypted, so shared_preferences is adequate for local storage because the token is already protected during network transit.
- b.flutter_secure_storage simply encrypts shared_preferences using a password supplied by the app, while both packages back up data to iTunes or Google Backup by default.
- c.shared_preferences writes tokens as plain text in local XML or plist files, whereas flutter_secure_storage encrypts them with keys bound to the iOS Keychain or Android Keystore.Correct
- d.shared_preferences is secure enough for tokens because Android and iOS app sandboxes prevent other apps from reading the underlying XML or plist files.
Why? this is the answer
flutter_secure_storage encrypts tokens using OS-level trust boundaries such as Android Keystore and iOS Keychain, while shared_preferences stores them as readable plain text. The sandbox distractor is wrong because sandboxing does not stop physical extraction, backups, or rooted-device access.
Just read this? Test yourself on what you have been reading.
Read the original → pub.dev
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on flutter — each one lists the topics its interview covers.
See open roles