Llaves de acceso con WebAuthn: registro y verificación

WebAuthn, el estándar del W3C detrás de las llaves de acceso, se basa en un par de claves por cuenta y por sitio. Al registrar, el autenticador crea el par y entrega al servidor la clave pública; la privada nunca sale de él. Al ingresar, el servidor envía un reto aleatorio, el navegador arma un paquete con ese reto, el tipo de ceremonia y el origen real de la página, y el autenticador lo firma junto con una huella del identificador del sitio (el RP ID).

El servidor verifica la firma con la clave pública guardada y comprueba que el reto sea el que emitió, que el origen sea uno de los suyos y que la huella del RP ID sea la de su dominio. Una página falsa no logra que el autenticador firme para el dominio verdadero, y aunque reenviara lo que obtiene, el origen y la huella no coincidirían.

En el registro, el servidor manda un identificador de usuario (user.id, el «user handle») que el autenticador guarda junto con la credencial y devuelve al ingresar. La especificación lo define como una secuencia opaca de hasta 64 bytes y exige que no contenga información que identifique a la persona, porque puede quedar guardado en el autenticador y verse fuera del control de la aplicación. Lo correcto es un valor aleatorio propio de la cuenta; el nombre visible va en otros campos.

Abre registro_llave.py y mira de dónde sale user.id.

Muchos autenticadores llevan un contador de firmas que sube en cada uso. La especificación indica que, si el valor guardado o el recibido no es cero y el recibido no es mayor que el guardado, puede existir un clon del autenticador, y deja a la parte que confía decidir qué hacer. Las llaves sincronizables entre dispositivos suelen enviar siempre cero: en ellas un cero constante es normal y no indica nada.

Abre verificar_ingreso.py para ver qué hace el servidor con el contador, y luego ceremonias.txt.

El autenticador marca dos cosas distintas. La presencia (UP) dice que alguien tocó la llave o aceptó el aviso. La verificación de usuario (UV) dice que el autenticador comprobó a la persona con un PIN o un dato biométrico. Con UV, una llave de acceso reúne dos factores: algo que se tiene y algo que se sabe o se es. Sin UV, es solo algo que se tiene. Cuando la llave es el único factor de la cuenta, esa diferencia decide si el ingreso es de uno o de dos factores.

Abre webauthn-config.txt y lee juntas la línea de uso y la de verificación en el ingreso.

El retroceso de la tarea 3 vino de un origen de red que ese administrador no había usado, a las diez y media de la noche, y al día siguiente el contador volvió a su secuencia desde la oficina. El servidor no lo comparó ni lo registró como alerta: la verificación pasó como cualquier otra.