Android: зберігання імені користувача та пароля?

178

Якщо я хочу зберегти ім’я користувача та пароль, які будуть використовуватися в додатку Android, який найкращий спосіб це зробити? Це через екран налаштувань (але що робити, якщо користувач пропустив це?), Або спливе діалогове вікно і запитає у користувача облікові дані? Якщо це так, я повинен підтримувати стан програми. Як би я це зробив?

android  authentication  storage  credentials 
— Легенда
джерело
4
stackoverflow.com/a/786588/1166727 Перевірте, що @RetoMeier (Tech Lead для розвитку Android в Google) повинен сказати про це.
— tony gil
1
Якщо ви шукаєте безпечний спосіб зберігання credentials.Read ця відповідь stackoverflow.com/a/20560574/730807
— Durai Amuthan.H
3
@Legend як ти вирішив свою проблему?
— Ерум
@Legend, ти можеш кинути трохи світла на збереження pwd у префіксах після шифрування .. тому що я хочу, щоб моя програма працювала без будь-якого Інтернету, то як мені отримати ключ .. (адже я не можу зберігати ключ на пристрої)
— eRaisedToX
Ви можете використовувати брелок для ключів для Api +18. developer.android.com/training/articles/keystore
— Golnar

Відповіді:

115

Більшість програм для Android та iPhone, які я бачив, використовують початковий екран або діалогове вікно для запиту облікових даних. Я думаю, що користувачеві громіздко часто доводиться вводити своє ім’я / пароль, тому зберігання цієї інформації має сенс з точки зору зручності використання.

Порада ( посібник для Android Dev ):

Загалом, ми рекомендуємо мінімізувати частоту запитів облікових даних користувачів - щоб зробити фішинг-атаки більш помітними та менше шансів на успішність. Замість цього використовуйте маркер авторизації та оновіть його.

Де можливо, ім’я користувача та пароль не повинні зберігатися на пристрої. Натомість виконайте початкову автентифікацію, використовуючи ім'я користувача та пароль, надані користувачем, а потім використовуйте короткочасний маркер авторизації, що залежить від послуги.

Використання AccountManger - найкращий варіант для зберігання облікових даних. SampleSyncAdapter є приклад того , як використовувати його.

Якщо це не є можливим для вас з якихось причин, ви можете повернутися до збережених облікових даних за допомогою механізму Налаштування . Інші програми не зможуть отримати доступ до ваших уподобань, тому інформація користувача не може бути легко відкрита.

— Ерік Левін
джерело
40
Я б сказав, що ризиковано зберігати інформацію про пароль, як і в налаштуваннях. На вкорінених телефонах можна отримати доступ до файлу налаштувань програми. Найменше, що ви можете зробити, - це оскаржувати пароль.
— Jayesh
51
Якщо у когось є ваш телефон і він здатний викорінити його, ви не зможете зробити це, щоб зберегти ваші дані. Обманювати пароль - це не погана ідея, але насправді це не набагато більший захист. Що важливіше - це те, що в ОС вже вбудовано багато шарів безпеки. Звичайно, ви не хочете робити нічого дурного, щоб обійти ці заходи. Напевно, краще використовувати таку систему, як OAuth, і зберегти маркер на пристрої замість імені користувача та пароля.
— Ерік Левін
4
Якщо ви користуєтесь AccountManager(відповідно до моєї відповіді, а @ Miguel - обхідним способом) і хтось отримає ваш мобільний телефон, їм потрібно буде продовжувати користуватися вашою SIM-карткою, щоб мати доступ до ваших облікових записів, оскільки це призведе до недійсності збережених облікових даних коли SIM змінюється.
— Джон О
3
Стирання облікових записів при зміні SIP було видалено досить давно, оскільки це мало сенсу, особливо для людей, які мають більше однієї SIM-карти. Кращею стратегією, якщо ваш телефон буде вкрадений, є перейти на сторінку свого облікового запису Google та скасувати доступ до конкретного пристрою.
— Микола Єленков
2
"Використання AccountManger - найкращий варіант для зберігання облікових даних." Чому?
— Люк
9

Ви повинні використовувати Android AccountManager . Це створено для цього сценарію. Це трохи громіздко, але одна з речей - це недійсність локальних даних, якщо SIM-карта зміниться, тому якщо хтось проведе ваш телефон і кине в нього нову SIM-картку, ваші облікові дані не будуть порушені.

Це також дає користувачеві швидкий і простий спосіб отримати доступ (і, можливо, видалити) збережені облікові дані для будь-якого облікового запису, який вони мають на пристрої, все з одного місця.

SampleSyncAdapter (наприклад, @Miguel) - приклад, який використовує збережені облікові дані облікових записів.

— Джон О
джерело
3
Де задокументовано, що AccountManager "визнає недійсними локальні дані, якщо зміниться SIM-карта"?
— Ерік Левін
Я не знаю про це. Однак я це повірив / прийняв / зрозумів після того, як у деяких користувачів мого додатка виникли проблеми з аутентифікацією після заміни SIM-карти.
— Джон О
1
Я не бачу його в коді JavaDocs або AccountManager. Це звучить як гарна особливість, було б просто добре перевірити це і зрозуміти деталі.
— Ерік Левін
2
За словами @NikolayElenkov, функцію недійсної зміни SIM-картки було видалено.
— ThomasW
2
@ThomasW у вас є цитування на це? Було б чудово отримати якийсь остаточний відповідь.
— Джон O
8

Я думаю, що найкращий спосіб захистити свій обліковий запис - спершу подумати про збереження пароля з шифруванням у файлі account.db, який не може бути легко доступним у не вкорінених пристроях, а у випадку вкоріненого пристрою хакеру потрібен ключ для розшифровки це.

Інший варіант - зробити всю свою автентифікацію, як це робить Gmail. після першої автентифікації з сервером Gmail. Ви отримали токен Auth, який буде використаний у випадку вашого пароля. цей маркер буде зберігатися в простому тексті. Цей маркер може бути помилковим у випадку зміни пароля з сервера.

останній варіант я рекомендую вам увімкнути двофакторну автентифікацію та створити пароль для свого пристрою. Після втрати пристрою все, що вам потрібно, це вимкнути цей пристрій.

— Різ
джерело
2
Чи можете ви опублікувати джерело, яке говорить, що account.db зашифровано? Або ви кажете, що конкретний пароль повинен бути зашифрований?
— Michał K
1
@ Riz, де зберігати ключ для шифрування, то ... тому що моя програма працює без Інтернету, тому не можу отримати її з мережі
— eRaisedToX
2

З новим обладнанням і API для відбитків пальців (Android 6.0) ви можете це зробити, як у цьому прикладі програми Github.

— Златко
джерело
8
Згаданий зразок проекту створює ключ в магазині ключів Android і використовує його для створення шифру для шифрування пароля. Зашифрований пароль і шифр зберігаються як кодовані рядки base64 у спільних налаштуваннях. Після успішної автентифікації за відбитками пальців секретний ключ витягується з магазину ключів Android і використовується разом з розшифрованим шифром для розшифрування декодованого пароля.
— mjwheat
@mjwheat це так корисно, щоб зрозуміти, що відбувається в прикладі. Дякую! Одне невелике введення тексту: "... для розшифрування закодованого пароля."
— muetzenflo
2

Вони класифікуються в порядку складності, щоб зламати вашу приховану інформацію .

  1. Зберігати в чіткому тексті

  2. Зберігайте зашифровані за допомогою симетричного ключа

  3. Використання Android Keystore

  4. Зберігайте зашифровані за допомогою асиметричних ключів

Джерело: Де найкраще зберігати пароль у додатку для Android

Сама Keystore шифрується за допомогою PIN-коду / пароля власного екрану користувача, отже, коли екран пристрою заблокований, Keystore недоступний. Майте це на увазі, якщо у вас є фонова послуга, яка може потребувати доступу до секретів вашої програми.

джерело: Просте використання Android Keystore для зберігання паролів та іншої конфіденційної інформації

— Дмитро Мельничук
джерело
1

Інформація на веб-сайті http://nelenkov.blogspot.com/2012/05/storing-application-secrets-in-androids.html є досить прагматичним, але на основі "використовує прихований андроїд-апіс". Це щось, що слід враховувати, коли ви дійсно не можете обійти зберігання облікових даних / паролів локально на пристрої.

Я також створив очищену суть цієї ідеї на https://gist.github.com/kbsriram/5503519, яка може бути корисною.

— кг
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.