Thanks Nikolay, this is a really good and helpful answer. So, from your experience - do you think most application developers go down the recommended token-based route? or just accept that AccountManager relies on root permissions and store the username and password directly (if there is no extremely sensitive data, e.g. credit card details)?.
On Tuesday, 12 February 2013 17:05:23 UTC, Nikolay Elenkov wrote: > > On Wed, Feb 13, 2013 at 12:11 AM, saladbowl > <[email protected]<javascript:>> > wrote: > > > > My understanding is that the AccountManager stores the > > username and password in plain text. On non-rooted devices this seems to > be > > relatively OK because the AccountManager DB requires root permissions. > > However, on rooted devices the username and password will be > compromised. > > Right. > > > > > How easy is it to gain root access/jailbreak an Android device? Should I > be > > concerned and assume that relying solely on AccountManager permissions > is a > > bad idea (that is my opinion at the moment). > > > > It depends on the vendor and on the device, but it's generally doable. As > for > being concerned, it depends who you are target users are and how valuable > the password is. Since the user generally knows the password (they > probably > put it there), protecting the it from themselves is not really worth > it. The real > problem might be a rogue app on a rooted devices that scans password DBs, > contacts, etc. and uploads them to a server, etc. If want to protect > against > this, you might want to do some more work. > > > I was > > thinking about encrypting/decrypting somehow (hashing is of no use as I > need > > to be able to get the original password as plain text) - but then I have > the > > problem of storing a key somewhere?. > > > > You can derive a key based on some device property such as ANDROID_ID, > MAC address, etc. You can mix those, hash them and then use a password > derivation algorithm to generate an actual key. Then use that to > encrypt/decrypt > your data. Of course, if someone knows the algorithm (say, reverses your > app), > they can generate the same key and decrypt the data (you can't really > protect > against that). But the rogue app mentioned above probably is not that > intelligent, > and is likely going for the low hanging fruit anyway. > > In short, it boils down to who/what are you trying to protect your data > from, > and how far are you willing to go to do it. > -- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
