5.3.2 Правила

При реализации приложения-аутентификатора необходимо соблюдать следующие правила:

5.3.2.1 Предоставление услуги аутентификатором должно быть приватным (обязательно)

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

5.3.2.2 Активность входа в систему должна осуществляться приложением-аутентификатором (обязательно)

Активность входа в систему для добавления новых учётных записей и получения токенов аутентификации должна осуществляться приложением-аутентификатором. Не следует подготавливать собственный интерфейс входа на стороне пользовательского приложения. Как упоминалось в начале этой статьи, преимущество учётного менеджера заключается в том, что крайне чувствительная информация/пароли не обязательно должны обрабатываться приложением. Если интерфейс входа подготовлен на стороне пользовательского приложения, пароль будет обрабатываться пользовательским приложением, что выходит за рамки стратегии учётного менеджера.

Используя приложение-аутентификатор для подготовки интерфейса входа, только пользователь устройства сможет взаимодействовать с ним. Это означает, что вредоносное приложение не сможет атаковать учётную запись путём прямого входа или создания учётной записи.

5.3.2.3 Активность входа в систему должна быть публичной и предполагать атаки со стороны других приложений (обязательно)

Активность входа в систему является системой, загружаемой пользовательским приложением. Чтобы обеспечить возможность отображения интерфейса входа даже при разных подписях ключей между пользовательским и аутентификационным приложениями, активность входа в систему следует реализовать как публичную. Публичная активность входа означает, что она может быть запущена вредоносным приложением. Никогда не доверяйте никакому вводу данных. Поэтому необходимо принять меры предосторожности, описанные в разделе «3.2 Осторожное и безопасное обращение с входными данными».

5.3.2.4 При необходимости открыть активность входа в системе использовать явное намерение KEY_INTENT с указанным именем класса активности входа (обязательно)

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

5.3.2.5 Чувствительная информация (например, данные учётных записей и токены аутентификации) не должна выводиться в журнал (обязательно)

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

Чувствительная информация, такая как пароли или токены аутентификации, не должна выводиться в журналы. Журналы могут быть прочитаны другими приложениями, что может привести к утечке информации. Кроме того, если утечка имени учётной записи может привести к потере, имя учётной записи также не должно выводиться в журнале.

5.3.2.6 Пароли не должны храниться в учётном менеджере (рекомендуется)

Два типа аутентификационной информации, пароли и токены аутентификации, могут храниться в одной учётной записи для регистрации учётного менеджера. Эта информация хранится в виде открытого текста в каталоге accounts.db в следующих местах:

• Android 4.1 и более ранние версии: /data/system/accounts.db
• Android 4.2 и более поздние версии: /data/system/0/accounts.db or /data/system/<UserId>/accounts.db

Для чтения содержимого accounts.db требуются права root или системные права, и его нельзя прочитать с рыночных устройств Android. В случае уязвимости в операционной системе Android злоумышленник может получить права root или системы, и информация об аутентификации в accounts.db будет подвержена риску.

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

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

5.3.2.7 Для связи между аутентификатором и онлайн-службой следует использовать HTTPS (обязательно)

Пароли или токены аутентификации являются так называемой информацией аутентификации. Если они будут перехвачены третьей стороной, третья сторона может выдать себя за действительного пользователя. Поскольку аутентификаторы используют онлайн-службы для отправки/получения этих типов информации аутентификации, следует использовать надёжный метод шифрования, такой как HTTPS.

5.3.2.8 После проверки правильности аутентификатора следует выполнить процесс учётной записи (обязательно)

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

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

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