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?
OWASP, an org that provides guidance to app developers, has a few reference material:
- The original Mobile Top Ten 2012 Insecure Data Storage reference -- https://www.owasp.org/index.php/Mobile_Top_10_2012-M1
- The updated Mobile Top Ten 2014 Insecure Data Storage reference -- https://www.owasp.org/index.php/Mobile_Top_10_2014-M2
- 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
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: