Как безопасно хранить учетные данные (пароль) в приложении Android?

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

1) KeyChain.
Only available in OS version 4.

2) Shared Preferences.
Он хранит данные в виде простого текста, хотя если я зашифрую данные, ключ шифрования может быть скомпрометирован путем декомпиляции кода приложения.

3) Access keystore daemon and store credentials in it.
(http://nelenkov.blogspot.com/2012/05/storing-application-secrets-in-androids.html) Requires another password to remember.

Пожалуйста, предложите мне лучший способ защиты учетных данных в приложениях для Android, таких как IPhone KeyChain.

 mjn07 апр. 2013 г., 21:37

Ответы на вопрос(2)

Hashing это решение не храните учетные данные в виде простого текста в общих настройках или на любом носителе.

Просто введите соль и хэшируйте пароль, чтобы сохранить его в sharedPreferences или в какой-либо встроенной базе данных.

Here is how it works:

Online

The plain(unhashed) password is sent to server for authentication & authorization upon successful login.

The salt either can be generated and returned from server to client or can be generated at client

Then store it as salt and hash the password and store it.

Offline

We’ll hash the user entered password using the salt which we stored

We'll compare with the hash which we stored upon successful login

If both are equal then we’ll let the user in else we won’t let the user in.

Advantages:

So Now you don't have to worry about version compatibility.

Even If device is rooted it's so hard to brute force the hash.

Even if someone decompiles/cracks the app it's so hard to reverse engineer

 22 мая 2014 г., 15:16
Да, для автономной аутентификации это было бы идеально. Я интерпретировал финансовое приложение как что-то, что вам понадобилось бы для проверки подлинности в веб-службе для получения информации. Может быть полезно отметить автономный аспект в вашем ответе.
 17 окт. 2014 г., 11:27
@RQube - соль должна быть динамической, логика генерации соли может быть сгенерирована сервером, чтобы декомпиляция приложения не открывала хакеру логику генерации соли.
 21 мая 2014 г., 16:41
Проблема с хранением с помощью хэша заключается в том, что хэши предназначены для улицы с односторонним движением. Я полагаю, что пользователь хочет сохранить пароль, чтобы он мог его вспомнить, чтобы пользователь не входил в систему каждый раз. Шифрование - это улица с двусторонним движением, хешей по дизайну нет.
 27 нояб. 2014 г., 00:38
Я не понимаю преимущества этого. Если сервер переходит от ожидающего пароля (который он затем хэширует) к ожидающему предварительно хешированному паролю, то, если хешированный пароль скомпрометирован, хакер может войти с ним на сервер. Им никогда не придется беспокоиться о том, какой реальный пароль у них есть, что сервер считает «паролем». быть
 22 мая 2014 г., 07:17
Я думаю, что разработчик хочет, чтобы пользователи могли входить в автономный режим. Так как вы сказали, что хеширование - это улица с односторонним движением, его нельзя реверсировать, поэтому он надежно защищен при совпадении хэшей, тогда аутентификация успешна.
Решение Вопроса

В настоящее время не является эквивалентом KeyChain для iPhone в Android. Если вы хотите сохранить что-то в секрете, не храните его на устройстве. Или, по крайней мере, не храните ключ / пароль, которым он зашифрован, на устройстве. Просто как тот.

Дополнительно:

1) Даже в ICS вы не можете использовать KeyChain напрямую для хранения секретов приложений (см. Блог в 3)

2) Это проблема только для рутованных телефонов или если кто-то имеет физический доступ к устройству.

3) Намного лучше запомнить один пароль, защищая все ваши учетные данные, чем пытаться запомнить несколько паролей. Кроме того, в ICS нет отдельного пароля, хранилище учетных данных защищено паролем разблокировки устройства.

 22 окт. 2012 г., 16:09
Вы в этом уверены? UID меняются, если вы устанавливаете другое приложение.
 23 окт. 2012 г., 03:19
На каком устройстве и версии Android это происходит? Вы действительно можете получить доступ к ключам из «новых»? приложение?
 Noor22 окт. 2012 г., 14:17
Я решил перейти к третьему варианту. Одна проблема, с которой я сталкиваюсь сейчас, заключается в том, что хранилище ключей связывает каждую запись с UID приложения. Таким образом, если установить другое приложение с тем же именем пакета, что и у предыдущего приложения (конечно, сначала я должен удалить предыдущее приложение) и с другой подписью приложения (сертификат подписи), то это приложение также может просматривать записи хранилища ключей, поскольку UID не изменяется.
 Noor22 окт. 2012 г., 22:31
На самом деле я пытаюсь взломать мое собственное приложение. Для этого я разработал другое приложение с тем же именем пакета и попытался установить его на свое устройство (здесь сертификат подписи для этого нового приложения отличается от реального приложения). При установке этого приложения андроид выдал ошибку, что «уже установлен существующий пакет с тем же именем с конфликтующей подписью». Следовательно, я удалил предыдущее приложение и установил новое приложение. В этот момент вместо назначения нового приложения андроид назначил тот же UID, который был назначен предыдущему приложению.
 19 апр. 2013 г., 08:35
Я знаю, что это старый, но в последней основной ветке Android, и ключи приложения удаляются при удалении приложения, таким образом, это не должно быть проблемой. С учетом вышесказанного интерфейс также значительно изменился, поэтому код в блоге, скорее всего, не будет работать, как в следующей версии Android (K-что угодно).

Ваш ответ на вопрос