Shared publicly  - 
Learn how to use cryptography to safely store user credentials, such as passwords and auth tokens, on local storage the right way -- 
by generating a truly random AES key when an application is first launched. 

And check your apps to ensure they're properly using SecureRandom.

Ricardo Domingos's profile photoPrashant K S's profile photoPETER AMEH's profile photoKonstantin Shilovsky's profile photo
I'm really thankful for this article. I worry a lot about security for my apps.
I hope the changes won't break my app as it was with changes in 2.2
We've been doing something like this for a while.  Got tired of pushing an update to our paid app just to have it show up on the hack/download sites within hours for free.
Its good nd safer to use

Dear +Android Developers: wouldn't it be possible to extend the API so that each app could get an app-specific secret key? It should be stored in a secure location only the system can access, if the device offers this capability. Some key chain approach? It would help security a lot if we don't have to depend of the internal memory, which becomes accessible once the device got rooted.
+Markus Junginger That would kinda defeat the purpose of the whole "random" aspect to this.  You'd then have to account for devices that don't offer that capability as you stated.  If a device is rooted by the user, then they know the risk don't they?  Hence the randomization to account for that.
+Kahil Nettleton No, the system would create this key randomly. The point is storing it securely. Alternatively, the key could probably derive from a single secret key built into a device.
+Markus Junginger Anything accessible to the system is also accessible to other apps if a device has been rooted.
Thanks for the post. Any best practice on how to store safely in your app different  key/secret pairs which uniquely identify your app when accessing different APIs? Thanks.
+Out of the Park Apps "Truly random" in the sense that it's actually making an attempt at being random, as opposed to injecting known state into SecureRandom to elicit deterministic (non-random) output. (See the attached blog post.)

That said, SecureRandom does pull from the system entropy pool under normal operation. So short of including a nuclear-powered hardward RNG with new phones, it's plenty random for pretty much anything likely to be thrown at it.

(Note: We can't publicly discuss Android's roadmap, so I neither confirm nor deny plans to include a nuclear-powered hardware RNG in future phones. Please ignore any Cherenkov radiation coming from your pocket.)
+Trevor Johns Couldn't there be a secret key burned into the device somehow that only the system could access? I'm not sure how the iOS guys do it, but they seems to have that. Yes, also iOS has been compromised, but I don't know if that it a consequence of jailbreaking or just some bug. I'm not a security expert, so I am happy to learn and better understand the current security situation.

Another aspect of system managed keys for apps might be that the system could incorporate the lock pattern or password info in the keys.
+Markus Junginger We already burn a serial number into ROM, but that doesn't really help here since any app can read that.

If you want to have a key stored securely in ROM, like you're proposing, then you need a TPM chip. These are cool pieces of technology — they can sign/decrypt without ever revealing the key to the OS.

However, to prevent a rogue app from impersonating the OS and submitting it's own decrypt request, it would need to prompt for a PIN/password whenever accessing protected data. At that point, the TPM doesn't really get you much more than what the software solution I described in the blog post will already get you.

(TPMs can do some other cool stuff, like self-destructing if they detect somebody trying to brute-force a PIN and validating the boot environment, but that's a different topic.)

If this sort of thing is interesting to you, here's a Wikipedia article on the topic:
I Hope It Does Not Break Any Off My Apps
+Trevor Johns TPM appears to be more secure than any software solution ;) Is a Secure Element, which is afaik already built into every Nexus phone is a TPM you are talking about? Are there any plans to make it available for application developers?
+sergej shafarenka Well, as I mentioned, the big benefit to a TPM in this application is that it can self-destruct if somebody's trying to brute-force your password. That's perhaps overkill for most apps -- especially given how often users forget passwords! Not to mention, there is a real hardware cost to adding it.

Unless you're doing something very specialized, a software solution is probably adequate.

As for the NFC Secure Element: I'm afraid I'm not the right person to comment on that. You'd want to talk to somebody from the NFC team.
I want that little black and green android figure.
Thanks for including the link.  Am I paranoid or should all posts do this?
+Android Developers I just want to chime in to appreciate the work you're doing to help us store our user credentials in a safer manner with cryptography. Keep up the good work. 
dua karte hai aap ko koi gan na ho aap ki ankhe kabhi nam na ho har mor par mile aap ko ek naya sathi par kisi mein hamari jagah banane ka dam na ho
I Hope It Does Not Break Any Off My Apps
Um,. technically it is NOT truly random, since the only truly random values can be generated by something such as noise. ALL "random number generators" are really psuedo-random number generators. Yeah, we make them so they take forever to repeat their output pattern, but there is a pattern to all of them, and it will eventually repeat. (And, yes, I've messed around with generating random numbers in both C++ and Java, so I know a few things about them,)
my device Micromax A57 I want top apps pls any one. and is there any free browsers to use I mean with out net balance we ll use internet?answer anyone pls

I don't quite get the following phrase :"Note that the security of this approach relies on safeguarding the generated key, which is is predicated on the security of the internal storage. Leaving the target file unencrypted (but set to MODE_PRIVATE) would provide similar security."

Does it mean that if I use MODE_PRIVATE the system takes care of  encrypting the data stored in shared preference? If No, where should I store the password generated on the first launch?
Thanks for the post.I like it.
I stumbled just now over the blog and wonder WHAT is the best approach for my app. All properties are stored in a database, I need to login to some server and wanna store the credentials in the DB. I.e. decryption is a requirement. And it would be good to know when I transfer the database to another device if I could still decrypt them. Ideas?
+Trevor Johns  I used this approach. Using PBKDF2WithHmacSHA1 algorithm gives a NoSuchAlgorithmException for 2.2 emulator. Is this expected? If so what is the alternative solution.
Can you help me understand something very basic here: you generate an AES key with the function you provided. What are you doing next? Are you going to encrypt the data with that key and store the resulting ciphertext in the internal storage? If so, then how are you going to decrypt the ciphertext later on, since the function that generates the key will generate different keys every time? AES is a simmetric key cryptographic algorithm, using the same key for both encryption and decryption.
+Markus Junginger maybe the play store could have an API for this, just like it has for the in-app-billing and expanstion library? 
+Android Developers I can understand how a password derived key for encryption helps in case of an alphanumeric password and how that eliminates the need for developers to store a key or user to enter one. They just have to enter their password.

However the code example in the original post clearly states passphraseOrPin as a parameter for the key generation. How can a PIN (as in numeric combination) be any good as input for key derivation? Doesn't that make brute force way too easy?

Also the hacker has the encrypted data to test if the brute forced key applied gives any valid decrypted data. 
I have the same question as Bogdan. How can the encryption key later be regenerated using the same passcode and seed, if the key generation function is pseudo-random? I do not wish to store the generated key on my device, rather regenerate it each time the user enters his passcode.
+Michal W. Regeneration of PDK is perfectly possible. Key for each encryption algorithm is that the same input will result in the same output (for the same key).

So first step is generating a hash from the user entered password. As long as the user remembers his password this will always result in the same hash value. The key for this encryption is no secret so that key can be stored on the device.

The second step is to use that generated hash value as an encryption key to protect actual data. The password or this resulting hash value is never stored! Any rule about password safety is applicable here. So this pattern is as safe as the password used to derive the key.
Add a comment...