Как WhatsApp перешел на безопасный и бесперебойный вход в систему для 1 миллиарда пользователей с помощью паролей

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

«Больше всего меня восхищает масштаб влияния WhatsApp. Даже небольшое улучшение WhatsApp затрагивает миллиарды пользователей по всему миру», — говорит Маянк Мануджа, Android-инженер из команды регистрации и доступа WhatsApp, который руководил разработкой и внедрением аутентификации на основе паролей для WhatsApp.

Building for an audience of this magnitude requires navigating a vast range of network conditions, device capabilities, and levels of digital literacy. Recognizing the potential early, WhatsApp committed to adopting passkeys in 2023, becoming one of the first major consumer apps to integrate the technology. By implementing passkeys, WhatsApp aimed to provide a fast, phishing-resistant option that significantly reduces user friction while providing robust protection against account takeovers and credential theft.   

Решение о внедрении кодовых ключей

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

Underneath, passkeys leverage public-private key cryptography to replace manual entry with biometric or screen lock authentication. This workflow drastically improves sign-in speeds by reducing the process to a single tap via a unified, bottom-sheet interface that keeps users engaged within the app's context. The benefits are twofold: passkeys offer users a streamlined login experience while simultaneously providing robust, native protection against phishing attacks. Crucially, they function reliably even in regions where traditional SMS OTP delivery can be inconsistent.

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

Интеграция на стороне клиента

From the WhatsApp developer perspective, the Credential Manager API provided a clean, unified interface that abstracted away the complexity of underlying credential providers. Once initial integration flows were mapped out, the API surface became straightforward, with credential creation and retrieval following well-defined request and response patterns. Find the implementation guide in the Android developer documentation .

While the happy path worked from the start, navigating a diverse user base across OEMs, multiple Android versions, and varied device configurations (such as PIN-only versus biometric, or Android 13 versus 14+) surfaced unprecedented edge cases. These included users without a screen lock, unexpected exception types, outdated Play Services, and inconsistent credential provider behavior.

Для преодоления этих препятствий команды WhatsApp и Google тесно сотрудничали и решили ряд задач:

• Optimizing the credential lookup flow : The initial lookup flow exhibited poor latency, particularly for users who had not yet created a passkey. Since the majority of WhatsApp users fall under this bucket in early stages, this added noticeable delay to nearly every sign-in. By instrumenting the call path and identifying bottlenecks together, WhatsApp significantly fastened up the process, achieving performance gains that ultimately benefited the entire Android ecosystem.
• Handling transient states : WhatsApp built a comprehensive error-handling layer to navigate device-specific hurdles such as password manager availability, screen lock not configured, intermittent connectivity issues, incompatible hardware, outdated play services, categorizing exceptions into recoverable and terminal states. This allowed for graceful degradation, if a passkey flow could not complete, the system safely fell back to traditional authentication without leaving the user in a broken state.
• Navigating OS-specific exceptions: When telemetry revealed device-specific hurdles such as GetPublicKeyCredentialDomException (Failed to decrypt credential) on certain Android 13 devices, and CreatePublicKeyCredentialDomException (Unable to get sync account) during passkey creation on Android 14, Google and the WhatsApp team investigated the root causes and implemented platform-level improvements to ensure smoother creation flows. You can find the comprehensive error guide here which lists common error codes and descriptions related to Credential Manager, and provides some information about their causes.

Улучшение пользовательского опыта

Because passkeys were an entirely new concept in early 2023, there were no established patterns for prompting their creation. Through extensive A/B testing, WhatsApp developed a contextual framework targeting users who would benefit most. This strategy continuously evolved: as Android OS flows matured into a streamlined, single-screen experience, WhatsApp simplified its own prompts to avoid redundant or confusing UI.

Архитектура серверной части и проблемы кроссплатформенности

On the backend, WhatsApp's server implements the standard WebAuthn/FIDO2 ceremonies. The backend is written in Erlang and calls the Rust webauthn-rs library through a native interface. This Rust library handles signature verification and credential parsing, allowing the internal code to remain focused on orchestration, storage, and product rules like eligibility, rate-limiting, and credential lifecycle.

Архитектура сервера организует эти основные процессы через четыре основные точки входа, объединенные в последовательности «Начало» и « Завершение» как для регистрации, так и для аутентификации:

1. Регистрация пароля

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

Erlang: Начать регистрацию

begin_registration(UserId) ->
    Existing = list_credentials(UserId),
    %% reuse the existing user handle, or mint a new one
    {UserHandle, IsNew} = user_handle(Existing),
    %% returns the client creation options and the server-side challenge state
    #{client_safe := CreationOptions, server_only := ChallengeState} =
        webauthn:start_registration(UserId, UserHandle, rp_config()),
    %% excludeCredentials: the user's existing credential IDs, so the device won't re-enroll one
    Options = with_exclude_credentials(CreationOptions, credential_ids(Existing)),
    store_challenge(UserId, ChallengeState),          %% short TTL
    IsNew andalso reserve_user_handle(UserId, UserHandle),
    Options.

• Идентификация пользователя: Сервер сначала проверяет наличие существующих учетных данных, чтобы либо повторно использовать существующий идентификатор пользователя, либо сгенерировать новый.
• Генерация параметров и запроса аутентификации: Эта функция вызывает библиотеку WebAuthn для генерации параметров аутентификации для клиента и безопасного состояния запроса аутентификации для сервера.
• Предотвращение дубликатов: система явно исключает существующие идентификаторы учетных данных пользователя, чтобы устройство случайно не зарегистрировало повторно пароль, который уже зарегистрирован.
• Запрос на сохранение: Сервер временно сохраняет запрос на сохранение с коротким временем жизни (TTL) и отправляет параметры обратно на клиентское устройство.

Erlang: Завершить регистрацию

finish_registration(UserId, Attestation) ->
    ChallengeState = get_challenge(UserId),          %% must exist and be unexpired
    #{credential_id := CredId, public_key := PubKey} =
        webauthn:finish_registration(Attestation, ChallengeState, rp_config()),
    ok = index_credential(CredId, UserId),            %% map credential_id -> account
    case multi_passkey_enabled(UserId) of
        true  -> add_credential(UserId, CredId, PubKey);      %% append (oldest evicted past the cap)
        false -> replace_credential(UserId, CredId, PubKey)   %% single-passkey mode
    end,
    notify_client(UserId, {passkey_created, CredId}),
    ok.

• Получение запроса: Сервер получает сохраненный запрос, проверяя, что он по-прежнему существует и не истек.
• Проверка аттестации: она передает ответ клиента (аттестацию) и запрос в библиотеку WebAuthn для проверки запроса и извлечения нового идентификатора учетных данных и открытого ключа.
• Индексирование учетных данных: новый идентификатор учетных данных напрямую сопоставляется с учетной записью пользователя для быстрого поиска в дальнейшем.
• Сохранение и управление лимитами: В зависимости от того, включена ли функция многопараметрических ключей, сервер либо добавит новые учетные данные в список пользователей (удалив самые старые, если будет достигнут лимит), либо заменит существующие в режиме однопараметрических ключей.

2. Аутентификация учетных данных

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

Erlang: Начало аутентификации

begin_authentication(UserId) ->
    Credentials = list_valid_credentials(UserId),
    #{client_safe := RequestOptions, server_only := ChallengeState} =
        webauthn:start_authentication(Credentials, rp_config()),
    store_challenge(UserId, ChallengeState),          %% short TTL
    RequestOptions.

• Получение действительных учетных данных: Сервер проверяет все действующие учетные данные, связанные с пользователем.
• Генерация запроса: программа использует эти учетные данные для формирования параметров запроса для клиента и генерирует новый запрос на стороне сервера.
• Сохранение и возврат: Как и при регистрации, задание сохраняется временно, а параметры запроса передаются в клиентское приложение.

Erlang: Завершение аутентификации

finish_authentication(UserId, Assertion) ->
    ChallengeState = get_challenge(UserId),
    Credentials = list_valid_credentials(UserId),
    case webauthn:finish_authentication(Credentials, Assertion, ChallengeState) of
        #{user_verified := true, credential_id := CredId, needs_update := NeedsUpdate} = Result ->
            %% webauthn tells us when the stored credential should be refreshed
            NeedsUpdate andalso refresh_credential(UserId, CredId, Result),
            mark_credential_used(UserId, CredId),
            {ok, CredId};
        _ ->
            {error, not_allowed}
    end.

• Проверка утверждения: Сервер получает сохраненный запрос и действительные учетные данные, а затем запрашивает у библиотеки WebAuthn проверку утверждения клиента.
• Обновление при необходимости: Если пользователь успешно подтвержден, сервер проверяет флаг needs_update. Библиотека WebAuthn использует этот флаг, чтобы сообщить, нужно ли обновить сохраненное состояние учетных данных на сервере.
• Завершение: Сервер помечает учетные данные как использованные и успешно завершает процесс входа в систему.

Чтобы узнать больше о регистрации сервера, следуйте инструкциям по интеграции здесь .

Передовые архитектурные соображения

Внедрение паролей на сервере в масштабах предприятия представляло собой уникальные проблемы, особенно в отношении архитектуры учетных записей и синхронизации устройств. Ашиш Чоудхари из команды бэкенда WhatsApp выделил основные трудности, с которыми они столкнулись:

1. Migrating to multiple passkeys per account: WhatsApp's legacy server logic was deeply intertwined with the assumption of a single credential per user. To support modern multi-device realities, they engineered a bounded list system that intelligently evicts the oldest credential once a limit is reached. To ensure absolute stability, this major structural shift was rolled out gradually through rigorous experimentation.
2. Balancing the credential lifecycle: Managing credential validity required a delicate touch. Invalidating credentials too aggressively forces needless re-enrollments, while being too lenient lets stale credentials pile up. WhatsApp solved this by implementing balanced lifecycle states to maintain tight security without frustrating users, complemented by automated background cleanup for inactive passkeys.

Переосмысление синхронизации между устройствами

This robust multi-passkey architecture also allowed WhatsApp to completely rethink cross-platform usability. The standard WebAuthn cross-device flow requires scanning a QR code on one device and authenticating over Bluetooth on another. However, WhatsApp found the Bluetooth dependency unreliable, and users often confused the new QR codes with the existing WhatsApp Web linking process.

Instead of forcing a fragile cross-device transport mechanism, WhatsApp allows users to hold passkeys natively across multiple ecosystems such as Google Password Manager on Android and iCloud Keychain on iOS. When users migrate to a new platform, they simply generate a fresh passkey during their next sign-in. This approach is completely frictionless for the user and operates seamlessly on top of the new multi-passkey server infrastructure.

Взгляд в будущее

Since launching passkeys, WhatsApp has witnessed robust organic adoption across its vast user base. By transforming the traditional multi-step sign-in process into a single, frictionless biometric gesture, the app has dramatically improved the user experience. Building on this momentum, WhatsApp is now expanding passkey utility beyond initial sign-ins, exploring seamless in-app re-authentication for sensitive account actions like passkey-encrypted backups.

В перспективе WhatsApp активно сотрудничает с партнерами по платформе, чтобы внедрять более простые способы создания учетных данных, ожидая, что барьеры для входа естественным образом снизятся по мере расширения возможностей биометрической идентификации устройств.

Рекомендации для разработчиков, создающих масштабируемые системы.

Для разработчиков, готовящихся к масштабной интеграции паролей, команда WhatsApp делится следующими важными рекомендациями:

• Внедрите систему классификации ошибок на раннем этапе: разделите многочисленные исключения диспетчера учетных данных на восстанавливаемые и терминальные состояния и определите четкие и корректные пути восстановления для каждого сценария.
• Разберитесь в процессе проверки соответствия требованиям: внедрите проверки возможностей устройства, такие как наличие блокировки экрана, биометрическое оборудование и версии Play Services, и разработайте сценарии, позволяющие заблаговременно исключать пользователей, не соответствующих требованиям, вместо того, чтобы прерывать процесс на полпути.
• Подготовьте ваше приложение к резервному варианту: используйте пароли в качестве оптимального основного метода аутентификации для совместимых устройств, но всегда сохраняйте традиционные методы в качестве надежного, универсального резервного варианта.
• Учитывайте фрагментацию версий ОС: поведение пароля может различаться в разных операционных системах. Проведите тщательное тестирование на Android 13, 14 и 15+ и учтите специфические для производителей устройства особенности пользовательского интерфейса выбора учетных данных.
• Предлагайте дополнительные услуги в контексте и проводите обучение: естественно представляйте процесс создания пароля во время действий, связанных с безопасностью. Четко подчеркивайте преимущества (скорость и безопасность), используя доступный язык, чтобы стимулировать внедрение среди пользователей.
• Проактивный мониторинг: экосистема развивается с каждым обновлением ОС. Постоянно отслеживайте задержки и закономерности ошибок, чтобы опережать изменения в устройствах.

Начните работу с Passkeys и менеджером учетных данных.

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

Если у вас возникнут какие-либо вопросы или проблемы, вы можете сообщить нам об этом через систему отслеживания проблем с учетными данными Android .