одна вещь, которая не указана, заключается в том, почему поле Password имеет значение null.
Проблема в этой реализации заключается в том, какой «пароль» следует использовать.
Здесь у меня сценарий с курицей и яйцом.
Если бы пароль был жестко задан в приложении, вы могли бы также использовать null (ИМХО ... но я 'Мы работали с исследователями безопасности и увидели, что их наборы инструментов и жестко заданный пароль, предоставляемый для вызова метода, занимают менее 2 минут работы, поэтому я могу предположить, что хакер может получить его даже за меньшее время ?), как если бы«пароль» был получен динамически из веб-API по небезопасному каналу .
Примечание : я не говорю, используя пустое / пустое значениепароль в порядке, я НЕ , продолжаю чтение.
Предлагая пользователю ввести пароль (в виде шаблона смахивания, ключевой фразы, пин-кода и т. д.) перед каждым хранилищем ключейиспользование сделает этот способ реализации "болеебезопасный », но какой ценой юзабилити приложения | пользователя, только вы и ваши пользователи могут определить это для варианта использования приложения.Лично мне нравится, когда мое банковское приложение запрашивает у меня пин-код и проверяет этот доступ через SMS и другой пин-код для входа, но это может быть только я.10
К вашему сведению: возможность взломать OAUTH-токены вашего пользователя для нескольких сайтов с помощью всего одного приложения и пароля будет весьма заманчивым для большинства хакеров и исследователей.
Работает как естьесть, но я беспокоюсь о безопасности
И вы должны быть.10
Эта реализация, на которую вы ссылаетесь, ИМХО, очень слабая.Как минимум, он должен проверять и использовать поставщика Android Keystone (AndroidKeyStore), если приложение работает по крайней мере на уровне API 18. Если ваше приложение поддерживает только 18+ (или работает на устройстве 18+), вы должныНЕ поддерживать свой собственный файл хранилища ключей (опять же ИМХО ... но я не могу представить, чтобы исследователь безопасности не согласился, но хотел бы услышать их аргумент, если они сочтут это необходимым).
Использование поставщика хранилища ключей удаляет вас иВаше приложение создает / поддерживает / защищает этот файл хранилища ключей, как это делает ОС, и оно использует токен пользователя / пароль / пин / шаблон блокировки / и т. д. ... для защиты самого фактического хранилища файлов. Больше никаких проблем с куриным яйцом.
Конечно, это не распространяется на проверку вашего приложения на выполнение корневых устройств, установку вредоносных приложений, текущие тесты эксплойтов, непатентованную и / или отсутствующую безопасность.патчи и т.д ... но, по крайней мере, это начало ?.(Я работал в некоторых действительно безопасных средах devops.)
Кроме того, эта реализация не проверяет безопасное оборудование;то есть.KeyInfo.IsInsideSecurityHardware, KeyInfo.IsUserAuthenticationRequirementEnforcedBySecureHardware и т.д.1048 *