Sample questions
Mobile Security StorageDifficulty 1
What is the main difference between "secure storage" and a plain local file/preferences store on a mobile device?
- aSecure storage survives an app uninstall while plain storage never does
- bIt is encrypted and OS-gated, unlike plain storage✓
- cSecure storage is only available for apps built with a paid developer account
- dSecure storage keeps data in memory only and never touches disk
Explanation:OS-level secure storage encrypts data at rest and ties access to the OS's key management and app identity, so reading it outside the app (e.g. via a rooted/jailbroken file browse) is far harder than reading a plain preferences file, which is typically stored as readable plaintext.
Mobile Security StorageDifficulty 1
Why is it recommended to keep an access token separate from a refresh token when storing authentication credentials on a mobile device?
- aBecause the two tokens must always use a different text encoding
- bBecause only one of them is allowed to be a string value
- cThe refresh token is long-lived, so leaking it is far worse✓
- dBecause mobile operating systems reject apps that store more than one token
Explanation:The refresh token can mint new access tokens for a long time, so its compromise is much more damaging. Separating them lets the app apply stricter storage/rotation rules to the refresh token while using the access token more freely for API calls.
Mobile Security StorageDifficulty 2
In the context of mobile authentication, what is a biometric "gate" typically used for?
- aGating access to an already-stored secret with a fingerprint/face check✓
- bReplacing the server-side authentication entirely so the backend never verifies the user again
- cGenerating the user's password from their fingerprint pattern
- dTransmitting the raw biometric image to the backend for storage
Explanation:Biometrics gate access to something already stored (e.g. unlocking a locally held credential) — the biometric data itself stays on-device and is not the secret being protected or sent anywhere.
Mobile Security StorageDifficulty 2
A junior developer stores the user's session token as a plain string inside the app's regular (unencrypted) local preferences file, reasoning "the app sandbox already protects it." What is the main risk being overlooked?
- aPlain preferences files cannot hold string values at all
- bThe app sandbox actively re-encrypts every file automatically, so this is actually safe
- cThe token would expire immediately if stored this way
- dRooted/jailbroken devices can read unencrypted files outside the sandbox✓
Explanation:The sandbox helps under normal OS conditions, but it is not the only threat model: rooted/jailbroken devices, insecure backups, or malware with elevated privileges can read unencrypted app files directly, defeating sandbox-only protection.
Mobile Security StorageDifficulty 1
What is "certificate pinning" in a mobile app's network layer, at a conceptual level?
- aSaving the server's response body to disk so it can be reused offline
- bVerifying the server's certificate matches a specific expected value✓
- cAttaching a physical security key to the device before making network calls
- dEncrypting the app's UI screenshots before storing them
Explanation:Certificate pinning narrows trust: rather than accepting any certificate chain that a trusted root CA has signed, the app checks the server's certificate/key against a value it already knows, which blocks certain interception attacks even if a CA is compromised.
Mobile Security StorageDifficulty 2
Why should sensitive values (tokens, passwords) generally be avoided in debug/console log statements, even in a development build?
- aLogs can be collected by crash-reporting tools or shared debug output✓
- bLog statements automatically get sent to the app store review team
- cThe OS deletes the app if sensitive text appears in a log
- dLogging a string value converts it to be permanently unencrypted in storage
Explanation:Even "just debug" logs can be picked up by system log buffers, crash/analytics SDKs, or shared logcat/console output, so sensitive values written there leak outside the controlled storage layer the developer thinks they are protecting.