I'm creating an app that logins to a remote API that doesn't implement oauth2 or another similar mechanism, and I want to know if is reasonably safe to assume that password will be safe if is stored in app private storage like Shared preferences or SQLite?

  • 1
    Storing passwords on a non-encrypted device is just asking for trouble.
    – user119199
    Aug 1, 2016 at 19:28
  • 1
    Safe against what? What is your threat model? Who's the attacker? Aug 1, 2016 at 21:55
  • I'm a little confused how the local storage mechanism and the remote API framework have anything to do with each other to be able to design a secure process. "... password will be safe ..." from what? When? What conditions are you worried about?
    – schroeder
    Aug 2, 2016 at 6:56

2 Answers 2


OWASP, an org that provides guidance to app developers, has a few reference material:

  1. The original Mobile Top Ten 2012 Insecure Data Storage reference -- https://www.owasp.org/index.php/Mobile_Top_10_2012-M1
  2. The updated Mobile Top Ten 2014 Insecure Data Storage reference -- https://www.owasp.org/index.php/Mobile_Top_10_2014-M2
  3. An iOS Developers Cheat Sheet which makes specific suggestions about where to store what types of data, when it is required of an app's functional tasks -- https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet#Insecure_Data_Storage_.28M1.29

For Android, I might suggest using secure-preferences instead of the Shared Preferences you suggested, or perhaps cwac-prefs. Check out examples of these in the book Android Security Cookbook.

On iOS, be sure to read the iOS Application Security book, which recommends Lockbox to store data in the Keychain, as well as methods to add and remove credentials. If you're building an iOS mobile app, this book is highly-recommended.

If you don't like or for some reason can't use Lockbox (or just want to try different options), then check out this idea from the book, Mobile Application Penetration Testing:

Utilize the different options provided by Apple, as we learned in the section Keychain data protection in Chapter 2, Snooping Around the Architecture. You can also utilize one of the simple wrapper PDKeyChainBindingController (https://github.com/carlbrown/PDKeychainBindingsController) to secure the keychain data. However, if the device is jailbroken then keychain information is not secure. It is recommended to use custom encryption techniques to encrypt the string that is stored in the keychain. Make the best use of the keychain services API (https://developer.apple.com/library/mac/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html).

The book also covers another issue related to credential storage in the Keychain:

On June 18, 2015, a password stealing vulnerability, also known as XARA (Cross Application Resource Attack), outlined for iOS and OS X cracked the Keychain services on jail broken and non-jail broken devices. The vulnerability is similar to the cross-site request forgery attack in web applications. In spite of Apple's isolation protection and its App Store's security vetting, it was possible to circumvent the security controls mechanism. It clearly provided the need to protect the cross-app mechanism between the operating system and the app developer. Apple rolled out a security update week after the XARA research. More information can be found at http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/

and provides details on the Keychain itself, should one utilize a jailbroken device to attempt to get access to it

Keychain in an iOS device is used to securely store sensitive information such as credentials, such as usernames, passwords, authentication tokens for different applications, and so on, along with connectivity (Wi-Fi/VPN) credentials and so on. It is located on iOS devices as an encrypted SQLite database file located at /private/var/Keychains/keychain-2.db


Answer provided is wrong, according to the Android native documentation

In general, we recommend minimizing the frequency of asking for user credentials -- to make phishing attacks more conspicuous, and less likely to be successful. Instead use an authorization token and refresh it.

Where possible, username and password should not be stored on the device. Instead, perform initial authentication using the username and password supplied by the user, and then use a short-lived, service-specific authorization token.

It is in the training docs here:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.