Примеры из практики
Zoho добилась шестикратного ускорения входа в систему благодаря интеграции с Passkey и Credential Manager.
10 минут чтения

Как разработчик Android, вы постоянно ищете способы повысить безопасность, улучшить пользовательский опыт и оптимизировать разработку. Zoho, комплексный облачный программный пакет, ориентированный на безопасность и бесперебойную работу, добился значительных улучшений, внедрив ключи аутентификации в свое приложение OneAuth для Android.
С момента внедрения паролей в 2024 году Zoho добилась скорости входа в систему до 6 раз выше, чем при использовании предыдущих методов, и 31%-ного ежемесячного роста числа пользователей паролей .
В данном исследовании рассматривается внедрение компанией Zoho технологии паролей и API Credential Manager для Android для решения проблем аутентификации. Подробно описывается процесс технической реализации и подчеркиваются достигнутые результаты.
Преодоление проблем аутентификации
Zoho использует комбинацию методов аутентификации для защиты учетных записей пользователей. В их число входит Zoho OneAuth , собственное решение для многофакторной аутентификации (MFA), поддерживающее как аутентификацию на основе паролей, так и аутентификацию без паролей с использованием push-уведомлений, QR-кодов и одноразовых паролей с привязкой ко времени (TOTP). Zoho также поддерживает федеративные входы в систему, позволяя аутентифицироваться с помощью языка разметки утверждений безопасности (SAML) и других сторонних поставщиков идентификации.
Проблемы
Компания Zoho, как и многие другие организации, стремилась повысить безопасность аутентификации и удобство использования, одновременно снижая операционные затраты. Основные проблемы, приведшие к внедрению паролей, включали:
- Уязвимости в системе безопасности: Традиционные методы, основанные на паролях, делали пользователей уязвимыми для фишинговых атак и утечек паролей.
- Проблемы, с которыми сталкиваются пользователи: Усталость от паролей приводит к их забыванию, разочарованию и увеличению зависимости от сложных процессов восстановления.
- Операционные неэффективности: Обработка запросов на сброс паролей и вопросов, связанных с многофакторной аутентификацией, приводила к значительным дополнительным расходам на поддержку.
- Проблемы масштабируемости: растущая база пользователей требовала более безопасного и эффективного решения для аутентификации.
Почему произошел переход на использование паролей?
В приложениях Zoho были внедрены ключи доступа (Passkeys) для решения проблем аутентификации, предлагающие беспарольный подход, который значительно повышает безопасность и удобство использования. Это решение использует аутентификацию, устойчивую к фишингу, синхронизированные с облаком учетные данные для легкого доступа между устройствами, а также биометрические данные (например, отпечаток пальца или распознавание лица), PIN-код или графический ключ для безопасного входа в систему, тем самым уменьшая уязвимости и неудобства, связанные с традиционными паролями.
Внедрение паролей в Credential Manager позволило Zoho сократить время входа в систему до 6 раз , значительно снизить затраты на поддержку, связанную с паролями, и добиться высокого уровня внедрения среди пользователей — количество входов с использованием паролей удвоилось за 4 месяца, а ежемесячный рост составил 31% . Теперь пользователи Zoho наслаждаются более быстрым и простым входом в систему, а также защитой от фишинга .

Реализация с использованием менеджера учетных данных на Android
Итак, как Zoho добилась таких результатов? Они использовали API Credential Manager для Android, а также рекомендованную библиотеку Jetpack для реализации аутентификации на Android.
Менеджер учетных данных предоставляет единый API, упрощающий обработку различных методов аутентификации. Вместо того чтобы использовать разные API для паролей, ключей доступа и федеративных входов (например, вход через Google), вы используете единый интерфейс.
Внедрение паролей в Zoho потребовало корректировок как на стороне клиента, так и на стороне сервера. Ниже представлен подробный анализ процесса создания паролей, входа в систему и реализации на стороне сервера.
Создание пароля

Для создания пароля приложение сначала получает данные конфигурации с сервера Zoho. Этот процесс включает в себя уникальную проверку, например, по отпечатку пальца или распознаванию лица. Эти данные проверки (в формате строки requestJson ) используются приложением для создания запроса CreatePublicKeyCredentialRequest . Затем приложение вызывает метод credentialManager.createCredential , который запрашивает у пользователя аутентификацию с помощью блокировки экрана устройства (биометрия, отпечаток пальца, PIN-код и т. д.).
После успешного подтверждения пользователем приложение получает новые учетные данные пароля, отправляет их на сервер Zoho для проверки, после чего сервер сохраняет информацию о пароле, привязанную к учетной записи пользователя. Сбои или отмены пользователем в процессе обработки фиксируются и обрабатываются приложением.
Войти
Приложение Zoho для Android инициирует процесс входа с помощью пароля , запрашивая у бэкэнд-сервера Zoho параметры входа, включая уникальный challenge . Затем приложение использует эти данные для формирования запроса GetCredentialRequest , указывающего на необходимость аутентификации с помощью пароля. После этого оно вызывает API Android CredentialManager.getCredential() с этим запросом. Это действие запускает стандартный системный интерфейс Android, предлагая пользователю выбрать свою учетную запись Zoho (если существует несколько паролей) и пройти аутентификацию с помощью настроенной блокировки экрана устройства (отпечаток пальца, сканирование лица или PIN-код). После успешной аутентификации Credential Manager возвращает подписанное утверждение (доказательство входа) приложению Zoho. Приложение пересылает это утверждение на сервер Zoho, который проверяет подпись по сохраненному открытому ключу пользователя и подтверждает запрос, завершая безопасный процесс входа.
Реализация на стороне сервера
Переход Zoho на поддержку паролей стал возможен благодаря тому, что их внутренние системы уже соответствовали стандарту FIDO WebAuthn, что упростило процесс реализации на стороне сервера. Однако для полной интеграции функциональности паролей все же потребовались определенные модификации.
Наиболее серьезная проблема заключалась в адаптации системы хранения учетных данных. Существующие методы аутентификации Zoho, которые в основном использовали пароли и ключи безопасности FIDO для многофакторной аутентификации, требовали иных подходов к хранению, чем пароли, основанные на криптографических открытых ключах. Для решения этой проблемы Zoho внедрила новую схему базы данных, специально разработанную для безопасного хранения открытых ключей паролей и связанных с ними данных в соответствии с протоколами WebAuthn. Эта новая система была построена вместе с механизмом поиска для проверки и извлечения учетных данных на основе информации о пользователе и устройстве, что обеспечивает обратную совместимость со старыми методами аутентификации.
Ещё одна корректировка на стороне сервера касалась реализации возможности обработки запросов с устройств Android. Запросы на ввод пароля, исходящие из приложений Android, используют уникальный формат источника ( android:apk-key-hash:example ), который отличается от стандартных веб-источников, использующих формат на основе URI ( https://example.com/app ). Логику сервера необходимо было обновить, чтобы корректно анализировать этот формат, извлекать хэш отпечатка SHA-256 сертификата подписи приложения и проверять его по предварительно зарегистрированному списку. Этот этап проверки гарантирует, что запросы на аутентификацию действительно исходят из приложения Zoho для Android, и защищает от фишинговых атак.
Этот фрагмент кода демонстрирует, как сервер проверяет формат исходного сертификата, специфичный для Android, и подтверждает правильность хеша сертификата:
val origin: String = clientData.getString("origin")
if (origin.startsWith("android:apk-key-hash:")) {
val originSplit: List<String> = origin.split(":")
if (originSplit.size > 3) {
val androidOriginHashDecoded: ByteArray = Base64.getDecoder().decode(originSplit[3])
if (!androidOriginHashDecoded.contentEquals(oneAuthSha256FingerPrint)) {
throw IAMException(IAMErrorCode.WEBAUTH003)
}
} else {
// Optional: Handle the case where the origin string is malformed }
}
Обработка ошибок
Zoho внедрила надежные механизмы обработки ошибок для управления ошибками как со стороны пользователей, так и со стороны разработчиков. Распространенная ошибка, CreateCredentialCancellationException , возникала, когда пользователи вручную отменяли настройку пароля. Zoho отслеживала частоту этой ошибки, чтобы оценить потенциальные возможности улучшения пользовательского опыта. Основываясь на рекомендациях Android по улучшению пользовательского опыта , Zoho предприняла шаги для лучшего информирования пользователей о паролях, обеспечения осведомленности пользователей о доступности паролей и стимулирования использования паролей при последующих попытках входа в систему.
Этот пример кода демонстрирует подход Zoho к обработке наиболее распространенных ошибок при создании паролей:
private fun handleFailure(e: CreateCredentialException) {
val msg = when (e) {
is CreateCredentialCancellationException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_CANCELLED", GROUP_NAME)
Analytics.addNonFatalException(e)
"The operation was canceled by the user."
}
is CreateCredentialInterruptedException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_INTERRUPTED", GROUP_NAME)
Analytics.addNonFatalException(e)
"Passkey setup was interrupted. Please try again."
}
is CreateCredentialProviderConfigurationException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_PROVIDER_MISCONFIGURED", GROUP_NAME)
Analytics.addNonFatalException(e)
"Credential provider misconfigured. Contact support."
}
is CreateCredentialUnknownException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_UNKNOWN_ERROR", GROUP_NAME)
Analytics.addNonFatalException(e)
"An unknown error occurred during Passkey setup."
}
is CreatePublicKeyCredentialDomException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_WEB_AUTHN_ERROR", GROUP_NAME)
Analytics.addNonFatalException(e)
"Passkey creation failed: ${e.domError}"
}
else -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_FAILED", GROUP_NAME)
Analytics.addNonFatalException(e)
"An unexpected error occurred. Please try again."
}
}
}
Тестирование паролей в интранет-средах
Компания Zoho столкнулась с первоначальной проблемой при тестировании паролей в закрытой интрасети. Процесс проверки паролей в Google Password Manager требует доступа к общедоступному домену для подтверждения домена проверяющей стороны (RP). Однако внутренняя тестовая среда Zoho не имела такого доступа к Интернету, что приводило к сбоям в процессе проверки и препятствовало успешному тестированию аутентификации с помощью паролей. Для решения этой проблемы Zoho создала общедоступную тестовую среду, которая включала размещение временного сервера с файлом ссылок на ресурсы и проверкой домена.
Этот пример из файла assetlinks.json , используемого в общедоступной тестовой среде Zoho, демонстрирует, как связать домен зависимой стороны с указанным приложением Android для проверки пароля.
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.zoho.accounts.oneauth",
"sha256_cert_fingerprints": [
"SHA_HEX_VALUE"
]
}
}
]
Интеграция с существующим сервером FIDO
Система паролей Android использует современный стандарт FIDO2 WebAuthn. Этот стандарт требует, чтобы запросы были в определенном формате JSON, что помогает поддерживать согласованность между нативными приложениями и веб-платформами. Для обеспечения поддержки паролей Android компания Zoho внесла незначительные изменения в совместимость и структуру, чтобы корректно генерировать и обрабатывать запросы, соответствующие требуемой структуре FIDO2 JSON.
Это обновление сервера включало в себя несколько конкретных технических корректировок:
1. Преобразование кодировки: Сервер преобразует кодировку URL-адреса Base64 (обычно используемую в WebAuthn для таких полей, как идентификаторы учетных данных) в стандартную кодировку Base64 перед сохранением соответствующих данных. Приведенный ниже фрагмент кода показывает, как rawId может быть закодирован в стандартный Base64:
// Convert rawId bytes to a standard Base64 encoded string for storage val base64RawId: String = Base64.getEncoder().encodeToString(rawId.toByteArray())
2. Формат списка транспортных протоколов: Для обеспечения согласованной обработки данных серверная логика обрабатывает списки транспортных механизмов (таких как USB, NFC и Bluetooth, которые определяют способ связи аутентификатора) в виде массивов JSON.
3. Согласование данных клиента: Команда Zoho скорректировала способ кодирования и декодирования поля clientDataJson на сервере. Это гарантирует точное соответствие структуры данных ожиданиям существующих внутренних API Zoho. Пример ниже иллюстрирует часть логики преобразования, применяемой к данным клиента перед их обработкой сервером:
private fun convertForServer(type: String): String {
val clientDataBytes = BaseEncoding.base64().decode(type)
val clientDataJson = JSONObject(String(clientDataBytes, StandardCharsets.UTF_8))
val clientJson = JSONObject()
val challengeFromJson = clientDataJson.getString("challenge")
// 'challenge' is a technical identifier/token, not localizable text.
clientJson.put("challenge", BaseEncoding.base64Url()
.encode(challengeFromJson.toByteArray(StandardCharsets.UTF_8)))
clientJson.put("origin", clientDataJson.getString("origin"))
clientJson.put("type", clientDataJson.getString("type"))
clientJson.put("androidPackageName", clientDataJson.getString("androidPackageName"))
return BaseEncoding.base64().encode(clientJson.toString().toByteArray())
}
Руководство пользователя и настройки аутентификации
Ключевым элементом стратегии Zoho в отношении паролей было стимулирование их использования пользователями при одновременном обеспечении гибкости для соответствия различным организационным требованиям. Это было достигнуто за счет тщательного проектирования пользовательского интерфейса и контроля политик.
Компания Zoho осознала, что у организаций разные потребности в области безопасности. Для удовлетворения этих потребностей Zoho внедрила следующие решения:
- Администрирование: Через панель администратора Zoho Directory администраторы могут назначить пароли в качестве обязательного метода аутентификации по умолчанию для всей организации. При включении этой политики сотрудники обязаны устанавливать пароль при каждом следующем входе в систему и использовать его в дальнейшем.
- Выбор пользователя: Если организация не устанавливает конкретную политику, отдельные пользователи сохраняют контроль над процессом. Они могут выбрать предпочтительный метод аутентификации при входе в систему, используя пароли или другие настроенные параметры в своих настройках аутентификации.
Чтобы сделать использование паролей привлекательным и простым для конечных пользователей, Zoho внедрила следующие решения:
- Простая настройка: Zoho интегрировала настройку паролей непосредственно в мобильное приложение Zoho OneAuth (доступно для Android и iOS ). Пользователи могут удобно настраивать свои пароли в приложении в любое время, что упрощает переход.
- Единый доступ: поддержка паролей была реализована во всех ключевых точках взаимодействия с пользователями, что гарантирует возможность регистрации и аутентификации с помощью паролей через:
- Мобильное приложение Zoho OneAuth (Android и iOS);
- Страница их веб- аккаунтов Zoho.
Этот метод гарантировал доступность и интеграцию процесса настройки и использования паролей в уже используемые платформы, независимо от того, было ли это предписано администратором или выбрано пользователем. Вы можете узнать больше о том, как создать удобные сценарии аутентификации с помощью паролей, изучив наше подробное руководство по пользовательскому интерфейсу для работы с паролями .
Влияние на скорость работы разработчиков и эффективность интеграции.
Менеджер учетных данных, как унифицированный API, также помог повысить производительность разработчиков по сравнению со старыми процессами входа в систему. Он упростил обработку множества методов аутентификации и API по отдельности, что привело к ускорению интеграции (с месяцев до недель) и уменьшению количества ошибок при внедрении. В совокупности это оптимизировало процесс входа в систему и повысило общую надежность.
Внедрение паролей в Credential Manager позволило Zoho добиться значительных и измеримых улучшений по всем направлениям:
- Значительное повышение скорости
- Вход в систему в 2 раза быстрее по сравнению с традиционной аутентификацией по паролю.
- Вход в систему в 4 раза быстрее по сравнению с использованием имени пользователя или номера мобильного телефона, при этом используется аутентификация по электронной почте или SMS с одноразовым паролем (OTP).
- Вход в систему в 6 раз быстрее по сравнению с аутентификацией по имени пользователя, паролю и SMS или OTP-коду от аутентификатора.
- Снижение затрат на поддержку
- Сокращение количества обращений в службу поддержки по вопросам, связанным с паролями , особенно в случае забытых паролей.
- Снижение затрат, связанных с двухфакторной аутентификацией на основе SMS, поскольку существующие пользователи могут пройти регистрацию напрямую с помощью паролей.
- Высокий уровень внедрения среди пользователей и повышенная безопасность:
- Количество входов в систему с помощью пароля удвоилось всего за 4 месяца, что свидетельствует о высокой популярности среди пользователей.
- Пользователи, переходящие на использование паролей, полностью защищены от распространенных фишинговых атак и утечек паролей.
- Благодаря 31%-ному ежемесячному росту внедрения , все больше пользователей ежедневно получают выгоду от повышения уровня безопасности и защиты от таких уязвимостей, как фишинг и подмена SIM-карт.
Рекомендации и лучшие практики
Для успешной реализации паролей на Android разработчикам следует учитывать следующие рекомендации:
- Воспользуйтесь API диспетчера учетных данных Android:
- Менеджер учетных данных упрощает получение учетных данных, сокращая трудозатраты разработчиков и обеспечивая единый процесс аутентификации.
- Обрабатывает пароли, ключи доступа и потоки федеративной авторизации в едином интерфейсе.
- Обеспечьте согласованность кодирования данных при миграции с других решений аутентификации FIDO:
- При переходе с других решений аутентификации FIDO, таких как ключи безопасности FIDO, убедитесь, что вы используете единообразный формат для всех входных/выходных данных.
- Оптимизировать обработку ошибок и ведение журналов:
- Внедрите надежную обработку ошибок для обеспечения бесперебойной работы пользователя.
- Предоставляйте локализованные сообщения об ошибках и используйте подробные журналы для отладки и устранения непредвиденных сбоев.
- Обучите пользователей вариантам восстановления пароля:
- Предотвращайте ситуации блокировки, заблаговременно информируя пользователей о вариантах восстановления.
- Отслеживайте показатели внедрения и отзывы пользователей:
- Отслеживайте вовлеченность пользователей, показатели использования паролей и процент успешных входов в систему, чтобы постоянно оптимизировать пользовательский опыт.
- Проведите A/B-тестирование различных сценариев аутентификации для повышения конверсии и удержания клиентов.
Использование паролей в сочетании с API Android Credential Manager предлагает мощное, унифицированное решение для аутентификации, которое повышает безопасность и упрощает взаимодействие с пользователем. Пароли значительно снижают риски фишинга, кражи учетных данных и несанкционированного доступа. Мы рекомендуем разработчикам протестировать это решение в своих приложениях и предоставить пользователям максимально безопасную аутентификацию.
Начните работу с ключами доступа и менеджером учетных данных.
Ознакомьтесь с возможностями использования паролей и менеджера учетных данных на Android, воспользовавшись нашим общедоступным примером кода .
Если у вас возникнут какие-либо вопросы или проблемы, вы можете сообщить нам об этом через систему отслеживания проблем с учетными данными Android .
Продолжить чтение

Примеры из практики
Компания Uber использовала API восстановления учетных данных Android для упрощения входа в систему на новых устройствах, прогнозируя сокращение количества ручных входов в систему на 4 миллиона в год и повышение уровня удержания пользователей.
Niharika Arora • 5 мин чтения

Примеры из практики
От последних новостей и развлечений до спорта и политики, X — это приложение для социальных сетей, цель которого — помочь почти 500 миллионам пользователей по всему миру получать полную информацию со всеми комментариями в режиме реального времени.
Niharika Arora • 3 мин чтения

Примеры из практики
Monzo — это британский цифровой банк с 15 миллионами клиентов, и их число продолжает расти. По мере масштабирования приложения команда разработчиков определила время запуска приложения как критическую область для улучшения, но опасалась, что это потребует значительных изменений в коде.
Ben Weiss • 2 мин чтения
Будьте в курсе событий
Получайте еженедельно самые свежие новости о разработке Android прямо на свою электронную почту.



