Стоит ли использовать AccountManager для хранения имен пользователей и паролей для приложений Android?

Я хотел бы знать, следует ли реализовать AccountManager для сохранения учетных данных пользователя, таких как имя пользователя, адрес электронной почты, пароли и т. д. Я не могу найти вескую причину для его использования.

Я не хочу, чтобы другие приложения имели доступ к Accounts, и я действительно не хочу, чтобы они отображались в настройках «Учетные записи и синхронизация» (хотя, возможно, это не имеет большого значения).

Итак, мой вопрос: должен ли я использовать его? За и против? Могу ли я скрыть Accounts от других приложений и сделать так, чтобы они не отображались в разделе «Учетные записи и синхронизация»?


person HGPB    schedule 05.06.2012    source источник


Ответы (2)


Этот принятый ответ на этот вопрос, вероятно, поможет вам... Что я должен использовать Android AccountManager для ?

Это также следует указать, как указано в сообщении выше, а также в AccountManager без SyncAdapter? , что у вас не может быть AccountManager без SyncAdapter, поэтому, вероятно, не стоит использовать это в вашей конкретной ситуации.

Я не вижу причин использовать AccountManager специально для хранения информации такого типа - в конце концов, это ничем не отличается от ручного хранения данных в вашей собственной базе данных или файле. Во всяком случае, это, вероятно, усложняет ситуацию - почему бы вам просто не сохранить его в SharedPreferences?

Единственная причина, по которой я мог бы подумать, что это будет способствовать использованию AccountManager, заключается в том, что вы хотите поделиться своей учетной записью с несколькими различными приложениями, поскольку данные хранятся в центральном хранилище данных Android, к которому могут получить доступ все приложения. Однако, если это не требуется, я думаю, что проще и проще просто использовать SharedPreferences

person wattostudios    schedule 05.06.2012
comment
Спасибо, это здорово. Скорее всего, у меня будет таблица пользователей в sqlite (поскольку я использую sqlite для других целей), поскольку я могу разрешить нескольким пользователям использовать приложение на одном устройстве. - person HGPB; 05.06.2012
comment
p.s. Я уже видел этот вопрос (первая ссылка), но на самом деле он не говорил со мной. И ни один принятый ответ не оставляет его открытым для спекуляций... - person HGPB; 05.06.2012
comment
Итак, примером AccountManager является взаимодействие, скажем, приложения Facebook и их приложения для обмена сообщениями для аутентификации? - person Atieh; 19.01.2015
comment
Этот ответ - именно то, чего вам следует избегать. Хранение пароля в файле или в базе данных, а не в безопасном месте, таком как AccountManager, просто раскрывает пароль любому другому приложению, установленному на устройстве. См. stackoverflow.com/questions/8174835/ - person Joan; 05.04.2016
comment
Комментарий @Joan верен, только если вы храните пароль во внешнем хранилище, а не во внутреннем хранилище. Цитата с сайта Android: Вы можете сохранять файлы прямо во внутренней памяти устройства. По умолчанию файлы, сохраненные во внутреннем хранилище, являются частными для вашего приложения, и другие приложения не могут получить к ним доступ (и пользователь). Когда пользователь удаляет ваше приложение, эти файлы удаляются. Я не вижу проблемы хранить токен в SharedPreferences, поправьте меня, если я что-то упустил. - person yongsunCN; 15.11.2016

Обзор

Использование AccountManager для хранения учетных данных является гораздо более безопасным способом, чем хранение в файле или базе данных SQL.
Файл может быть получен любым другим приложением, в отличие от AccountManager Android будет обеспечивать, чтобы только ваше приложение могло получить доступ к ключ.

Но даже AccountManager не полностью защищен в случае потери телефона, например, дополнительную информацию см. здесь.

Хорошая практика (ы)

  • Я бы порекомендовал использовать AccountManager и не хранить пароль в чистом виде, а в виде хэша.
  • А для повышения уровня безопасности еще лучше хранить выделенный токен устройства, доставленный веб-службой и связанный с учетной записью (на стороне веб-службы), и позволить пользователю отозвать токен.

Фигово

  • Не храните открытый пароль или даже хешированный пароль в виде файла или базы данных, доступной для всех.
  • Никогда не храните четкий пароль, вместо этого всегда используйте хэш.

Смотрите также

person Joan    schedule 16.04.2014
comment
Как вы думаете, почему SQL DB или свойства приложения более небезопасны, чем Android AccountManager? AFAIK, доступ к SQLite-DB/свойствам, специфичным для приложения, может быть получен только самим приложением или с корневым доступом, так что это то же самое, что и для AccountManager. Разница лишь в том, что почти каждый злоумышленник будет заглядывать в AccountManager, так как его структура хорошо известна. - person Compufreak; 22.01.2015
comment
Потому что вам нужны права root для доступа к базе данных SQLite AccountManager. Запись пароля в собственной БД — большая ошибка, так как любое другое приложение может получить к нему доступ, не будучи root. - person Joan; 05.04.2016
comment
Я знаю, что это старо, но комментарий Джоан неверен. Никакое другое приложение не может получить доступ к базе данных другого приложения без корневого доступа. - person Crearo Rotar; 12.07.2019
comment
Тот факт, что ваши файлы изолированы, не является причиной для хранения учетных данных на диске. Вы бы хранили свои пароли на своем компьютере в открытом виде или в менеджере паролей? - person Joan; 13.07.2019
comment
Даже Google не рекомендует этого делать: по возможности не храните имена пользователей и пароли на устройстве. Вместо этого выполните первоначальную аутентификацию, используя имя пользователя и пароль, предоставленные пользователем, а затем используйте недолговечный токен авторизации для конкретной службы. Доступ к службам, доступным для нескольких приложений, должен осуществляться с помощью AccountManager. Если возможно, используйте классAccountManager для вызова облачной службы и не храните пароли на устройстве. developer.android.com/training/articles/security-tips - person Joan; 13.07.2019