Should you use AccountManager for storing Usernames and Passwords for an Android app?

问题

I would like to know if one should implement AccountManager to save user credentials such as username, email, passwords etc. I can't find a good reason to use it myself.

I don't want other applications to have access to the Accounts and I don't really want them showing in the "Accounts and Sync" settings (although maybe that's not a big deal).

So my question is: should I use it? Pros/cons? Can I hide the Accounts from other apps and stop them from appearing in "Accounts and Sync"?

回答1:

This accepted answer to this question would probably help you... What should I use Android AccountManager for?

It should also be pointed out, as mentioned in the above post and also in AccountManager without a SyncAdapter? , that you can't have an AccountManager without a SyncAdapter, so its probably not good to use this for your particular situation.

I can't see any reason to use an AccountManager specifically for storing this type of information - at the end of the day, its no different to manually storing the data yourself in your own database or file. If anything, it probably complicates things - why don't you just store it in SharedPreferences?

The only reason I could think of that would encourage the use of AccountManager would be if you want to share your account across a number of different apps, as the data is stored in the central Android datastore which can be accessed by all apps. However, if this isn't required, I think its probably easier and simpler to just use SharedPreferences

回答2:

Overview

Using an AccountManager to store credentials is a much secure way than storing in a file or a SQL DB.
A file can be retrieved by any other app unlike via AccountManager Android will enforce that only your app will be able to access to the key.

But even the AccountManager is not fully secured in case of lost phone for example, see this for more info.

Good practice(s)

I would recommend to use the AccountManager and not store the password in clear but the hash.
And for a better level of security it's even better to store a device dedicated token delivered by the webservice and associated to the account (on the webservice side) and enable the user to revoke the token.

Not good

Do not store a clear or even hashed password as a file or in a DB accessible by anyone.
Never store a clear password but always work with a hash instead.