Toda clave de acceso necesita un socio silencioso

Las claves de acceso mejoran considerablemente la seguridad de la autenticación, pero no resuelven todos los problemas relacionados con la identidad. En este tutorial aprenderás por qué el registro y la recuperación de cuentas siguen siendo complicados, cómo la autenticación silenciosa subsana esas carencias y cómo crear el flujo completo utilizando la Verify API de Vonage. 

Las contraseñas son el error sin solucionar más antiguo del software, y las claves de acceso son la primera solución que elimina el secreto compartido en lugar de reubicarlo. Todas las soluciones anteriores, desde los códigos de un solo uso hasta los enlaces mágicos, solo trasladaban ese secreto a un lugar mejor protegido. Si quieres conocer a fondo esa historia, así como las dos etapas que hacen que una clave de acceso funcione, lo he explicado en  «Las claves de acceso desde los principios básicos». 

Las claves de acceso están ganando popularidad rápidamente. Al sustituir la contraseña por un par de claves pública y privada —en el que la clave privada nunca sale del dispositivo del usuario y el servidor solo conserva la clave pública—, impiden por diseño que el phishing funcione. El navegador simplemente se negará a utilizar la clave en un sitio web incorrecto, y una base de datos de credenciales robadas se convierte en una lista de claves públicas sin valor alguno. 

Sin embargo, a pesar de todas esas ventajas, las claves de acceso siguen dejando dos puertas sin proteger. No pueden indicarte quién está llamando a la puerta la primera vez que alguien se registra, ni pueden permitir que un usuario legítimo vuelva a entrar cuando ha perdido su última clave de acceso. Ambas puertas son precisamente donde  la autenticación silenciosa de Vonage  destaca: verifica la posesión de un número de teléfono mediante la tarjeta SIM y la red del operador, sin códigos que introducir y sin nada que un phisher pueda interceptar. 

Dos factores resistentes al phishing y sin fricciones, cada uno de los cuales cubre el punto ciego del otro. Veamos por qué encajan tan bien y, a continuación, creemos el flujo con la  API de Verify v2. 

Cómo funcionan las claves de acceso y WebAuthn

Las claves de acceso  son credenciales de WebAuthn. Al registrarse, el dispositivo genera un par de claves dentro de un hardware seguro y envía la clave pública al servidor. Al iniciar sesión, el servidor emite un desafío aleatorio, el dispositivo lo firma tras realizar un gesto biométrico o introducir un PIN, y el servidor verifica la firma. Una simple pulsación con el pulgar ya constituye una autenticación multifactorial: algo que tienes (el dispositivo) más algo que eres (el gesto). Es fundamental destacar que el navegador solo ofrece una clave de acceso en el dominio para el que se creó, por lo que ya no es el usuario quien decide si una página de inicio de sesión es auténtica. 

Autenticación silenciosa verifica la identidad de un usuario a través de su tarjeta SIM. Tu backend inicia una verificación con la Verify API v2, recibe una «check_url» y el dispositivo del usuario abre esa URL a través de su conexión móvil. El operador confirma directamente, cotejando sus propios registros, que la solicitud procede del dispositivo al que pertenece ese número de teléfono, y devuelve una respuesta GSM verificada. No se envía ningún SMS, no hay que introducir ningún código de seis dígitos y no aparece nada en pantalla que un atacante pueda utilizar para engañar al usuario mediante ingeniería social. La autenticación se produce directamente entre el operador y el dispositivo móvil, lo que descarta por completo el clásico método de phishing con OTP. 

Fíjate en la simetría: 

• Una clave de acceso acredita la posesión de una clave privada vinculada a tu servicio. 

• La autenticación silenciosa (Silent Auth) demuestra la posesión de una tarjeta SIM vinculada a un número de teléfono. 

Ninguno de los dos factores muestra nunca un secreto al usuario, por lo que ninguno le proporciona un secreto que pueda revelar. 

Cuando las claves de acceso necesitan un aliado

Es importante tener en cuenta que el registro, el inicio de sesión y la recuperación no son la misma pregunta formulada tres veces. El registro pregunta «¿quién es esta persona?», el inicio de sesión pregunta «¿es esta la misma persona que se registró?» y la recuperación pregunta «¿es realmente esta persona, ahora que ya no existe lo que lo demostraba?». 

Las claves de acceso ofrecen una respuesta excelente a la cuestión del inicio de sesión, pero no dan ninguna respuesta a las otras dos. 

El problema del primer día

Una clave de acceso solo puede demostrar que la persona que inicia sesión es la misma que se registró. No dice nada sobre quién se registró. El primer día aún no existe ninguna clave de acceso, por lo que la mayoría de los registros sin contraseña recurren al eslabón más débil de todo el sistema: una dirección de correo electrónico, sin verificar o verificada mediante un enlace que, a su vez, es susceptible de ser objeto de phishing. Si un atacante crea la cuenta de victim@example.com antes que la víctima y le asigna su propia clave de acceso, ya tienes un problema de apropiación de cuenta antes incluso de que el usuario haya aparecido. 

Vincular el registro a un número de teléfono verificado de forma silenciosa cambia el panorama. La cuenta se crea asociándola a un número que el operador acaba de confirmar que está activo en ese dispositivo, y solo entonces se lleva a cabo el proceso de generación de la clave de acceso. La clave de acceso amplía ahora de forma criptográfica una identidad que realmente has verificado, en lugar de una que el usuario simplemente haya introducido. 

The Day One Problem

El problema del último dispositivo

La segunda vía es la recuperación. Un usuario con una clave de acceso vinculada a un único dispositivo está a un solo teléfono perdido de quedarse sin acceso, e incluso las claves de acceso sincronizadas dan por hecho que el usuario sigue teniendo acceso a su cuenta en la plataforma. La mayoría de los productos recurren a un enlace mágico enviado por correo electrónico, lo que reintroduce silenciosamente todo lo que las claves de acceso habían eliminado: un token de portador, guardado en una bandeja de entrada y protegido por una contraseña. 

Silent Auth te ofrece una vía de recuperación con el mismo nivel de seguridad que el dispositivo que se está recuperando. Nuevo teléfono, mismo número: el operador garantiza la autenticidad de la tarjeta SIM, el usuario vuelve a registrar una clave de acceso y, en ningún momento, el código se transmite por un canal que un atacante pueda interceptar. 

El caudal combinado

Este es el ciclo de vida completo: 

1. Registro: Verifica el número de teléfono con Silent Auth, crea la cuenta y, a continuación, registra la primera clave de acceso. 

2. Cada vez que inicies sesión a partir de entonces: Solo con Passkey. Un solo gesto, sin necesidad de conectarse a la red del operador, y funciona en cualquier dispositivo, incluidos los ordenadores de sobremesa. 

3. Recuperación o un nuevo dispositivo sin sincronización: Vuelve a realizar la autenticación silenciosa y, a continuación, registra una clave de acceso de sustitución. 

4. Medida adicional opcional: Para acciones de alto riesgo (pagos, cambio de correo electrónico, añadir una nueva clave de acceso desde un navegador no reconocido), ejecuta una comprobación de autenticación silenciosa en segundo plano como segundo factor independiente. 

The Combined FlowLas claves de acceso se encargan de lo cotidiano; Silent Auth se encarga de los casos extremos.  Vamos a escribir las partes interesantes. 

Requisitos previos

• Tu aplicación está registrada en el Registro de la Red para su uso en producción (durante el desarrollo, el entorno de pruebas te ofrece todo lo que necesitas; más información al respecto a continuación). 

• Un backend capaz de mantener una sesión; los fragmentos de código que aparecen a continuación utilizan curl sin modificaciones y JavaScript de navegador, para que puedas adaptarlos a la pila tecnológica que prefieras. 

• Un teléfono con una tarjeta SIM y datos móviles para probar la fase de autenticación silenciosa. 

• A  Account de la API de Vonage

Paso 1: Verificar el número de forma discreta al registrarse

Cuando un nuevo usuario introduce su número de teléfono, tu backend inicia un proceso de verificación. La matriz «workflow» es donde reside la magia: primero «silent_auth», con un sistema de respaldo por SMS para los casos en los que «Silent Auth» no pueda ejecutarse. 

 

curl -X POST https://api.nexmo.com/v2/verify \ 
  -H "Authorization: Bearer $JWT" \ 
  -H "Content-Type: application/json" \ 
  -d '{ 
    "brand": "ACME Inc", 
    "workflow": [ 
      { "channel": "silent_auth", "to": "447700900000" }, 
      { "channel": "sms", "to": "447700900000" } 
    ] 
  }' 

La respuesta contiene un request_id y, en el caso de la autenticación silenciosa, un check_url: 

{ 
  "request_id": "b3a2f4d0-1234-4d6e-9f00-example00000", 
  "check_url": "https://api-eu-3.vonage.com/v2/verify/b3a2f4d0.../silent-auth/redirect" 
} 

Entrega el check_url al cliente y haz que el dispositivo lo abra a través de su conexión móvil. Este es el único requisito imprescindible de Silent Auth: si la solicitud se envía a través de Wi-Fi, el operador nunca la ve y la comprobación falla. Las bibliotecas de clientes de Vonage para iOS y Android existen precisamente para forzar que la solicitud se realice a través de datos móviles, incluso cuando se está conectado a una red Wi-Fi, así que utilízalas en lugar de crear una propia. 

El dispositivo sigue una breve cadena de redireccionamientos hasta la red del operador y devuelve un código, que tu cliente envía a tu servidor backend y este, a su vez, reenvía a Verify: 

curl -X POST https://api.nexmo.com/v2/verify/$REQUEST_ID \ 
  -H "Authorization: Bearer $JWT" \ 
  -H "Content-Type: application/json" \ 
  -d '{ "code": "'$CODE'" }' 

Un "status": "completed" significa que el operador ha avalado la tarjeta SIM. Se ha verificado la identidad del usuario y, aquí viene lo mejor: , no se ha dado cuenta de nada. No ha recibido ningún código, ni ha tenido que teclear nada. Desde su punto de vista, introdujo un número de teléfono y se le identificó automáticamente. 

Durante el desarrollo, añade "sandbox": true a la entrada del flujo de trabajo y utiliza el Network Registry Playground, para que puedas probar todo el flujo sin necesidad de cobertura de operador. 

Paso 2: Registrar la primera clave de acceso

Ahora, y solo ahora, crea la cuenta y realiza inmediatamente el proceso de registro de WebAuthn. La API nativa del navegador ya no necesita dependencias: 

// The server generated these options, including a random challenge 
// and the user object: { id: userHandle, name: phoneOrEmail } 
const options = PublicKeyCredential.parseCreationOptionsFromJSON(optionsJSON); 

 
// The OS prompts for Touch ID / Face ID / Windows Hello and mints 
// the key pair inside secure hardware. The private key never leaves. 
const credential = await navigator.credentials.create({ publicKey: options }); 

 
await fetch("/registration", { 
  method: "POST", 
  headers: { "Content-Type": "application/json" }, 
  body: JSON.stringify({ credential: credential.toJSON() }), 
}); 

Hay dos ajustes del lado del servidor que convierten una credencial normal en una clave de acceso. Estos ajustes requieren un credencial (resident_key: "required") para que el inicio de sesión pueda realizarse sin nombre de usuario, y requieren la verificación del usuario del gesto biométrico. Ten en cuenta que la opción `user_verification` solo solicita el gesto al navegador; es tu paso de verificación en el servidor el que también debe comprobar el indicador de verificación del usuario en la respuesta del autenticador; de lo contrario, un cliente manipulado podría saltarse la verificación biométrica y reducir silenciosamente tu inicio de sesión multifactorial a uno de un solo factor. Una vez comprobado esto, Verify la respuesta con el desafío que has enviado, almacena la clave pública y la Account dispondrá ya de una credencial resistente al phishing vinculada a un número de teléfono verificado por el operador. 

Una nota de diseño: el número de teléfono que has verificado es una buena etiqueta legible para la clave de acceso (user.name en las opciones de creación), y la especificación WebAuthn incluye explícitamente los números de teléfono junto con las direcciones de correo electrónico y los nombres de usuario precisamente con este fin. Pero nunca lo utilices como identificador de usuario (user.id); este debe seguir siendo un identificador aleatorio opaco. 

Paso 3: Inicia sesión con la clave de acceso y nada más

El inicio de sesión diario nunca recurre a la Verify API. El usuario pulsa un botón, el navegador muestra el selector de cuentas, con un solo gesto se firma el desafío del servidor y ya está. 

Llegados a este punto, quizá te preguntes: ¿por qué no utilizar Silent Auth también en cada inicio de sesión, como una capa adicional de seguridad? La respuesta es que, de hacerlo, estarías pagando por una cobertura que no necesitas y perdiendo la que sí necesitas. Un inicio de sesión con clave de acceso ya demuestra la posesión de un dispositivo registrado, además de una lectura biométrica reciente, y funciona en ordenadores de sobremesa, con Wi-Fi y en un sótano sin señal —precisamente los lugares a los que no llega la verificación del operador. Cada verificación de Silent Auth también supone un viaje de ida y vuelta por la red (además de una tarifa por verificación). Esto está bien para momentos puntuales del ciclo de vida, pero se nota como una carga en cada inicio de sesión. En otras palabras, reserva la verificación del operador para los momentos en los que la clave de acceso no pueda «hablar». 

Paso 4: Recuperación: la misma puerta que el primer día

Cuando un usuario pierde su última clave de acceso, la recuperación consiste simplemente en el Paso 1, seguido de nuevo del Paso 2: Verify de forma silenciosa el número con el que se registró, abrir una sesión de recuperación de corta duración y permitirle generar una nueva clave de acceso. El flujo de trabajo con el sistema de respaldo por SMS ya gestiona los casos complicados, como el de un usuario cuyo nuevo teléfono tiene una tarjeta SIM pero que en ese momento está utilizando un ordenador de sobremesa, en cuyo caso Verify simplemente pasa al siguiente canal del flujo de trabajo. 

Vale la pena ser sincero sobre esta disyuntiva, ya que no existe una solución milagrosa en lo que respecta a la verificación de usuarios. La recuperación vinculada a un número de teléfono hereda el propio ciclo de vida de dicho número. Los Numbers se reutilizan y existe el fraude por cambio de tarjeta SIM; por eso, el hecho de que Silent Auth compruebe en los propios registros del operador si se han producido cambios recientes en la tarjeta SIM supone un nivel de seguridad significativamente mayor que un código por SMS, y por eso debes considerar la recuperación como un buen momento para realizar un escrutinio adicional (notificarlo a todos los demás canales de los que dispongas, retrasar las acciones de alto valor y registrar el suceso). 

Por qué esta combinación funciona

Si nos alejamos un poco, la imagen resulta agradablemente nítida: 

Todo sistema de credenciales presenta un problema de arranque y un problema de recuperación, y la mayoría de las soluciones recurren discretamente a un canal vulnerable al phishing precisamente en esos dos momentos. La combinación de claves de acceso con la autenticación silenciosa mantiene todo el ciclo de vida basado en factores que nunca revelan ningún secreto al usuario. El navegador comprueba el origen, el operador comprueba la tarjeta SIM y al usuario nunca se le pide que evalúe nada que un suplantador pudiera falsificar, lo que significa que nunca hay ningún secreto que un suplantador pueda sonsacarle al usuario. 

Y ese es precisamente el acuerdo que prometía el título: «Silent Auth» es el socio silencioso. Aporta el capital que permite poner en marcha la empresa, interviene cuando el negocio necesita un rescate y permanece invisible el resto del tiempo, mientras que «Passkey» se encarga de la gestión diaria. 

Conclusión

Si quieres profundizar en cualquiera de las dos partes, la  guía de autenticación silenciosa  trata los temas de cobertura y registro en el Registro de red, mientras que el  tutorial «Introducción a la autenticación silenciosa»  recorre el check_url flujo de principio a fin con un backend de Node.js, y la  artículo sobre buenas prácticas profundiza en el diseño de flujos de trabajo alternativos. 

¿Has combinado las claves de acceso con la autenticación basada en red, o tienes pensado hacerlo? Nos encantaría saber cómo te va.