19

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"?

wattostudios
  • 8,446
  • 13
  • 40
  • 54
HGPB
  • 4,185
  • 7
  • 47
  • 83

2 Answers2

18

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

Community
  • 1
  • 1
wattostudios
  • 8,446
  • 13
  • 40
  • 54
  • Thanks, thats great. I will most likely have a user table in sqlite (since i'm using sqlite for other stuff), since I may allow multiple users to use the app on the same device. – HGPB Jun 05 '12 at 14:38
  • p.s. I have already seen this question (first link) but it didn't really speak to me. And no accepted answer sort of leaves it open to speculation... – HGPB Jun 05 '12 at 14:40
  • 1
    So an example of `AccountManager` is the interaction of let's say, Facebook app and their messenger app for authentication? – Atieh Jan 19 '15 at 15:10
  • 3
    This answer is exactly what you should avoid doing. Storing a password in a file or in a DB instead of in a secure place like an AccountManager is just exposing the password to any other app installed on the device. See http://stackoverflow.com/questions/8174835/what-protects-android-accountmanager-passwords-from-being-read-by-other-apps – Joan Apr 05 '16 at 14:34
  • @Joan's comment is correct only if you store password in external storage, not internal storage. Quoting from android site: "You can save files directly on the device's internal storage. By default, files saved to the internal storage are private to your application and other applications cannot access them (nor can the user). When the user uninstalls your application, these files are removed." I don't see any problem to store a token in SharedPreferences, correct me if I missed something. – yongsunCN Nov 14 '16 at 22:11
9

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.

See also

Community
  • 1
  • 1
Joan
  • 3,695
  • 1
  • 22
  • 35
  • 6
    Why do you think a SQL DB or app properties are more insecure than Android AccountManager? AFAIK an app-specific SQLite-DB/properties can only be accessed by the app itself, or with root-access - so it's the same as for the AccountManager. The only difference is that almost every attacker will look into the AccountManager as its structure is well known. – Compufreak Jan 22 '15 at 12:55
  • 1
    Because you need root rights to access the SQLite DB of AccountManager. Writing the password in your own DB is a big mistake as any other app can access it without being root. – Joan Apr 05 '16 at 14:20
  • I know this is old, but Joan's comment is wrong. No other app can access another app's database without root access. – Crearo Rotar Jul 12 '19 at 11:45
  • Just because your files are sandboxed is not a reason to store credentials clear on disk. Would you store your passwords on your computer in a clear txt or in a password manager? – Joan Jul 13 '19 at 16:52
  • Even Google discourage to do this: "Where possible, don't store user names and passwords on the device. Instead, perform initial authentication using the user name and password supplied by the user, and then use a short-lived, service-specific authorization token. Services that are accessible to multiple applications should be accessed using AccountManager. If possible, use theAccountManager class to invoke a cloud-based service and don't store passwords on the device." https://developer.android.com/training/articles/security-tips – Joan Jul 13 '19 at 16:52