How to Securely Store Credentials (Password) in Android Application

Android: Storing username and password?

Most Android and iPhone apps I have seen use an initial screen or dialog box to ask for credentials. I think it is cumbersome for the user to have to re-enter their name/password often, so storing that info makes sense from a usability perspective.

The advice from the (Android dev guide) is:

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.

Using the AccountManger is the best option for storing credentials. The SampleSyncAdapter provides an example of how to use it.

If this is not an option to you for some reason, you can fall back to persisting credentials using the Preferences mechanism. Other applications won't be able to access your preferences, so the user's information is not easily exposed.

How to securely store credentials (password) in Android application?

The is no equivalent of iPhone's KeyChain in Android currently. If you want to keep something secret, don't store it on the device. Or at least, don't store the key/password it is encrypted with on the device. Simple as that.

Additionally:

1) Even on ICS, you cannot use the KeyChain directly to store application secrets (see blog post in 3))

2) This is only a problem for rooted phones, or if someone has physical access to the device.

3) It is a lot better to remember a single password, protecting all of you credentials, than trying to remember multiple passwords. Additionally, on ICS, there is no separate password, the credential storage is protected by the device unlock password.

Storing secrets and credentials inside of an Android App

This really all depends on how secure you need or want your app to be, and how sensitive are those credentials. Since storing and retrieving them from server-side is not an option, your best bet would be to embed them somewhere in the code. APKs can be decompiled really easily, thus your credentials will always be accessible some way or another. The real question is how difficult you want the reversing process to be.

From there the credentials will be retrieved as BuildConfig.FIELD_NAME. Can I be 100% sure that those cannot be extracted from the apk when reverse-engineering it?

I'm 100% sure it can be retrieved :). Java will not encrypt any strings, and they'll be all stored as raw text in the dex files, ready to be grep'd.

From there, your next steps would be to encrypt the keys in the code, using a static key. Some tools will do that for you, like DexGuard, Dasho, Dexprotector -- you could also come up with your own solution.This article explains it well.

Keep in mind that both your own solution, or a solution provided by a third-party tool might prove easy to reverse: see this example for DexGuard. Please also note that when decrypted at runtime, these credentials will be in clear in the device's RAM, thus allowing a debugger to easily read them.

Your next best bet is to go with encrypted strings inside native code: harder to reverse and track down, yet still doable.

Then you can use whitebox cryptography, again with third-party tools like those proposed by Inside Secure. This will essentially blend both an encryption algorithm and a key into obfuscated native code, which might give you hard to reverse & hard to debug encryption/decryption methods. Here you would only include encrypted credentials in your app, and they would be decrypted securely inside the whitebox. The whitebox is generally very secure (but not impossible to crack), but once decrypted, credentials will be in clear in the device's memory. This would protect more thoroughly against simple decompilation.

Then... I don't think you can go much further than that without involving a hardware solution (KeyStore, embedded Secure Element) and a server to back everything up.

---

Related Topics