Cómo WhatsApp actualizó el acceso seguro y sin problemas para 1, 000 millones de usuarios con llaves de acceso

WhatsApp es la plataforma de mensajería más grande del mundo, con miles de millones de usuarios en todo el mundo. Es la herramienta de comunicación predeterminada para personas de diversas regiones, ya que conecta a los usuarios a través de mensajes privados, confiables y seguros.

"Lo que más me entusiasma es la gran escala del impacto de WhatsApp. Incluso una pequeña mejora en WhatsApp afecta a miles de millones de usuarios en todo el mundo", dice Mayank Manuja, ingeniero de Android del equipo de Registro y Acceso de WhatsApp, que lideró el diseño y la implementación de la autenticación basada en llaves de acceso para WhatsApp. 

Para crear un producto para un público de esta magnitud, se debe tener en cuenta una amplia variedad de condiciones de red, capacidades de dispositivos y niveles de alfabetización digital. WhatsApp reconoció el potencial de las llaves de acceso desde el principio y se comprometió a adoptarlas en 2023, lo que la convirtió en una de las primeras aplicaciones para consumidores importantes en integrar la tecnología. Con la implementación de las llaves de acceso, WhatsApp buscaba proporcionar una opción rápida y resistente al phishing que redujera significativamente la fricción de los usuarios y, al mismo tiempo, proporcionara una protección sólida contra la apropiación de cuentas y el robo de credenciales.   

La decisión de adoptar las llaves de acceso

En WhatsApp, ofrecer varios métodos de acceso es clave para que los usuarios puedan mantenerse conectados y recuperar el acceso cuando sea necesario. Las llaves de acceso ofrecen a los usuarios una experiencia de acceso optimizada con un solo toque que elimina los riesgos de phishing y funciona de manera confiable incluso en regiones donde la entrega de mensajes de OTP puede ser inconsistente. 

En segundo plano, las llaves de acceso aprovechan la criptografía de claves públicas y privadas para reemplazar el ingreso manual por la autenticación biométrica o con bloqueo de pantalla. Este flujo de trabajo mejora drásticamente la velocidad de acceso, ya que reduce el proceso a un solo toque a través de una interfaz unificada de hoja inferior que mantiene la interacción de los usuarios en el contexto de la app. Los beneficios son dobles: las llaves de acceso ofrecen a los usuarios una experiencia de acceso optimizada y, al mismo tiempo, proporcionan una protección nativa y sólida contra los ataques de phishing. Fundamentalmente, funcionan de manera confiable incluso en regiones donde la entrega de OTP por SMS tradicional puede ser inconsistente.

Contar con métodos de acceso a la cuenta sólidos y diversos garantiza que los usuarios nunca pierdan el acceso a lo que más les importa.

Integración del cliente

Desde la perspectiva de los desarrolladores de WhatsApp, la API de Credential Manager proporcionó una interfaz limpia y unificada que abstrajo la complejidad de los proveedores de credenciales subyacentes. Una vez que se trazaron los flujos de integración iniciales, la superficie de la API se volvió sencilla, con la creación y recuperación de credenciales siguiendo patrones de solicitud y respuesta bien definidos. Encuentra la guía de implementación en la documentación para desarrolladores de Android. 

Si bien la ruta de acceso feliz funcionó desde el principio, navegar por una base de usuarios diversa en diferentes OEMs, múltiples versiones de Android y diversas configuraciones de dispositivos (como solo PIN frente a datos biométricos, o Android 13 frente a 14 o versiones posteriores) reveló casos extremos sin precedentes. Entre ellos, se incluyen usuarios sin bloqueo de pantalla, tipos de excepciones inesperadas, Servicios de Play desactualizados y un comportamiento incoherente del proveedor de credenciales.

Para superar estos obstáculos, los equipos de WhatsApp y Google colaboraron estrechamente y abordaron varios desafíos:

• Optimización del flujo de búsqueda de credenciales: El flujo de búsqueda inicial presentaba una latencia deficiente, en especial para los usuarios que aún no habían creado una llave de acceso. Como la mayoría de los usuarios de WhatsApp se encuentran en este grupo en las etapas iniciales, esto agregó una demora notable a casi todos los accesos. Instrumentando la ruta de llamada y, juntos, identificando los cuellos de botella, WhatsApp aceleró significativamente el proceso y logró mejoras de rendimiento que, en última instancia, beneficiaron a todo el ecosistema Android.
• Manejo de estados transitorios: WhatsApp creó una capa integral de manejo de errores para sortear obstáculos específicos de los dispositivos, como la disponibilidad del administrador de contraseñas, el bloqueo de pantalla no configurado, los problemas de conectividad intermitentes, el hardware incompatible y los Servicios de Play desactualizados, y categorizar las excepciones en estados recuperables y terminales. Esto permitió una degradación elegante: si un flujo de llave de acceso no se podía completar, el sistema recurría de forma segura a la autenticación tradicional sin dejar al usuario en un estado de error.
• Navegación por excepciones específicas del SO: Cuando la telemetría reveló obstáculos específicos de los dispositivos, como GetPublicKeyCredentialDomException (no se pudo desencriptar la credencial) en ciertos dispositivos con Android 13 y CreatePublicKeyCredentialDomException (no se pudo obtener la cuenta de sincronización)  durante la creación de llaves de acceso en Android 14, Google y el equipo de WhatsApp investigaron las causas raíz y, luego, implementaron mejoras a nivel de la plataforma para garantizar flujos de creación más fluidos. Puedes encontrar la guía de errores completa aquí, en la que se enumeran los códigos de error comunes y las descripciones relacionadas con el Administrador de credenciales, y se proporciona información sobre sus causas. 

Refina la experiencia del usuario

Como las llaves de acceso eran un concepto completamente nuevo a principios de 2023, no había patrones establecidos para solicitar su creación. A través de pruebas A/B exhaustivas, WhatsApp desarrolló un marco contextual orientado a los usuarios que más se beneficiarían. Esta estrategia evolucionó de forma continua: a medida que los flujos del SO Android maduraron y se convirtieron en una experiencia optimizada de una sola pantalla, WhatsApp simplificó sus propios mensajes para evitar una IU redundante o confusa.

Arquitectura del servidor y obstáculos multiplataforma

En el backend, el servidor de WhatsApp implementa las ceremonias estándar de WebAuthn/FIDO2. El backend está escrito en Erlang y llama a la biblioteca de Rust webauthn-rs a través de una interfaz nativa. Esta biblioteca de Rust controla la verificación de firmas y el análisis de credenciales, lo que permite que el código interno se enfoque en la organización, el almacenamiento y las reglas de productos, como la elegibilidad, la limitación de frecuencia y el ciclo de vida de las credenciales.

La arquitectura del servidor organiza estas ceremonias principales a través de cuatro puntos de entrada principales, vinculados en secuencias Begin y Finish para el registro y la autenticación:

1. Registro de llaves de acceso

Esta secuencia controla la emisión de opciones de creación para el cliente, la verificación de la certificación una vez que el cliente confirma la creación correcta y la persistencia segura de la credencial.

Erlang: Comienza el registro

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.

• Identifica al usuario: Primero, el servidor verifica si hay credenciales existentes para reutilizar un identificador de usuario existente o generar uno nuevo.
• Generar opciones y un desafío: Llama a la biblioteca de WebAuthn para generar las opciones de creación para el cliente y un estado de desafío seguro para el servidor.
• Evita duplicados: Excluye de forma explícita los IDs de credenciales existentes del usuario para que el dispositivo no vuelva a inscribir accidentalmente una llave de acceso que ya está registrada.
• Almacenar el desafío: El servidor almacena temporalmente el desafío con un tiempo de actividad (TTL) corto y envía las opciones de vuelta al dispositivo cliente.

Erlang: Finalizar registro

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.

• Recuperar el desafío: El servidor recupera el desafío almacenado y se asegura de que aún exista y no haya vencido.
• Verificar la certificación: Pasa la respuesta del cliente (certificación) y el desafío a la biblioteca de WebAuthn para verificar la solicitud y extraer el ID de credencial y la clave pública nuevos.
• Indexar la credencial: El ID de la credencial nueva se asigna directamente a la cuenta del usuario para realizar una búsqueda rápida más adelante.
• Guarda y administra los límites: Según si la función de varias llaves de acceso está habilitada, el servidor agregará la credencial nueva a la lista del usuario (y expulsará la más antigua si se alcanza un límite) o reemplazará la existente en el modo de llave de acceso única.

2. Autenticación de credenciales

Al igual que en la creación, el servidor de la app controla el flujo de autenticación organizando la secuencia de acceso. Esto incluye verificar la aserción después de que el cliente se autentique correctamente y actualizar de forma dinámica las credenciales almacenadas cada vez que WebAuthn indique que es necesario realizar una actualización.

Erlang: Inicia la autenticación

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.

• Recuperar credenciales válidas: El servidor busca todas las credenciales válidas actualmente asociadas con el usuario.
• Generar desafío: Usa esas credenciales para crear opciones de solicitud para el cliente y genera un nuevo desafío del servidor.
• Almacenamiento y devolución: Al igual que en el registro, el desafío se guarda temporalmente y las opciones de solicitud se pasan a la app cliente.

Erlang: Finaliza la autenticación

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.

• Verifica la aserción: El servidor recupera el desafío almacenado y las credenciales válidas, y, luego, le pide a la biblioteca de WebAuthn que verifique la aserción del cliente.
• Actualiza si es necesario: Si el usuario se verifica correctamente, el servidor verifica una marca needs_update. La biblioteca de WebAuthn usa este indicador para señalar si el estado de la credencial almacenada debe actualizarse en el servidor.
• Finalización: El servidor marca la credencial como usada y completa correctamente el proceso de acceso.

Para obtener más información sobre el registro del servidor, sigue la guía de integración aquí. 

Consideraciones arquitectónicas avanzadas 

Implementar llaves de acceso en el servidor a gran escala presentó desafíos únicos, en particular en lo que respecta a la arquitectura de las cuentas y la sincronización de dispositivos. Ashish Choudhary, del equipo de backend de WhatsApp, destacó los principales obstáculos que enfrentaron:

1. Migración a varias llaves de acceso por cuenta: La lógica del servidor heredado de WhatsApp estaba estrechamente vinculada con la suposición de una sola credencial por usuario. Para admitir las realidades multidispositivo modernas, diseñaron un sistema de lista limitada que expulsa de forma inteligente la credencial más antigua una vez que se alcanza un límite. Para garantizar una estabilidad absoluta, este cambio estructural importante se lanzó de forma gradual a través de una experimentación rigurosa.
2. Equilibrar el ciclo de vida de las credenciales: La administración de la validez de las credenciales requería un toque delicado. Invalidar las credenciales de forma demasiado agresiva fuerza reinscripciones innecesarias, mientras que ser demasiado permisivo permite que se acumulen credenciales obsoletas. WhatsApp resolvió este problema implementando estados de ciclo de vida equilibrados para mantener una seguridad estricta sin frustrar a los usuarios, complementados con una limpieza automática en segundo plano de las llaves de acceso inactivas.

Rethinking Cross-Device Synchronization

Esta sólida arquitectura de múltiples llaves de acceso también permitió que WhatsApp replanteara por completo la usabilidad multiplataforma. El flujo estándar de WebAuthn entre dispositivos requiere escanear un código QR en un dispositivo y autenticarse a través de Bluetooth en otro. Sin embargo, WhatsApp descubrió que la dependencia de Bluetooth no era confiable y que los usuarios solían confundir los nuevos códigos QR con el proceso de vinculación existente de WhatsApp Web.

En lugar de forzar un mecanismo de transporte frágil entre dispositivos, WhatsApp permite que los usuarios conserven las llaves de acceso de forma nativa en varios ecosistemas, como el Administrador de contraseñas de Google en Android y el llavero de iCloud en iOS. Cuando los usuarios migran a una plataforma nueva, simplemente generan una llave de acceso nueva durante su próximo acceso. Este enfoque no presenta dificultades para el usuario y funciona sin problemas sobre la nueva infraestructura de servidor de llaves de acceso múltiples.

Qué trae el futuro

Desde el lanzamiento de las llaves de acceso, WhatsApp ha sido testigo de una sólida adopción orgánica en su amplia base de usuarios. Al transformar el proceso tradicional de acceso de varios pasos en un solo gesto biométrico sin complicaciones, la app mejoró drásticamente la experiencia del usuario. Aprovechando este impulso, WhatsApp ahora está expandiendo la utilidad de las llaves de acceso más allá de los accesos iniciales, explorando la reautenticación fluida en la app para acciones sensibles de la cuenta, como las copias de seguridad encriptadas con llaves de acceso.

De cara al futuro, WhatsApp colabora activamente con plataformas asociadas para ser pionero en rutas de creación de credenciales con menos fricción, anticipando que las barreras de entrada disminuirán de forma natural a medida que se expandan las capacidades biométricas de los dispositivos. 

Recomendación para desarrolladores que crean a gran escala

Para los desarrolladores que se preparan para integrar llaves de acceso a gran escala, el equipo de WhatsApp comparte estas recomendaciones fundamentales:

• Invierte en una taxonomía de errores desde el principio: Clasifica la amplia variedad de excepciones del Credential Manager en estados recuperables y terminales, y define rutas de resguardo claras y elegantes para cada situación.
• Comprende tu embudo de elegibilidad: Instrumenta verificaciones de las capacidades del dispositivo, como la presencia de bloqueo de pantalla, el hardware biométrico y las versiones de los Servicios de Play, y diseña flujos para excluir de forma proactiva a los usuarios no aptos en lugar de fallar a mitad del flujo.
• Prepara tu app para el resguardo: Usa llaves de acceso como un método de autenticación principal óptimo para los dispositivos compatibles, pero conserva siempre los métodos tradicionales como un resguardo universal y confiable.
• Planifica para la fragmentación de versiones del SO: El comportamiento de las llaves de acceso puede variar según el sistema operativo. Realiza pruebas exhaustivas en Android 13, 14 y 15 o versiones posteriores, y ten en cuenta las variaciones específicas de los OEM en la IU de selección de credenciales.
• Ofrece ventas incrementales de forma contextual y educa a los usuarios: Presenta la creación de llaves de acceso de forma natural durante las acciones relevantes para la seguridad. Destaca claramente la propuesta de valor (velocidad y seguridad) con un lenguaje accesible para impulsar la adopción por parte de los usuarios.
• Supervisa de forma proactiva: El ecosistema evoluciona con cada actualización del SO. Realiza un seguimiento continuo de los patrones de latencia y errores para mantenerte al tanto de los cambios en los dispositivos.

Comienza a usar las llaves de acceso y Credential Manager

Prueba las llaves de acceso y el Administrador de credenciales en Android con nuestra guía de integración y el código de muestra público.

Si tienes alguna pregunta o problema, puedes comunicarte con nosotros a través de la herramienta de seguimiento de problemas de Android Credentials.