En este documento, se analiza qué es userVerification en WebAuthn y los comportamientos del navegador que se generan cuando se especifica userVerification durante la creación o autenticación de la llave de acceso.
¿Qué es la "verificación del usuario" en WebAuthn?
Las llaves de acceso se basan en la criptografía de clave pública. Cuando se crea una llave de acceso, se genera un par de claves pública/privada, el proveedor de la llave de acceso almacena la clave privada y la clave pública se devuelve al servidor del usuario de confianza (RP) para que la almacene. El servidor puede autenticar a un usuario verificando una firma firmada por la misma llave de acceso con la clave pública vinculada. La marca "usuario presente" (UP) en una credencial de clave pública demuestra que alguien interactuó con el dispositivo durante la autenticación.
La verificación del usuario es una capa de seguridad opcional que busca afirmar que la persona correcta estuvo presente durante la autenticación, no solo alguna persona, como lo hace la presencia del usuario. En los smartphones, esto suele hacerse con el mecanismo de bloqueo de pantalla, ya sea biométrico, un PIN o una contraseña. Se informa si se realizó la verificación del usuario en la marca "UV" que se muestra en los datos del autenticador durante el registro y la autenticación de la llave de acceso.
Cómo se validan la UP y la UV en el servidor
Las marcas booleanas de presencia del usuario (UP) y de usuario verificado (UV) se indican al servidor en el campo de datos del autenticador. Durante la autenticación, se puede validar el contenido del campo de datos del autenticador verificando la firma con la clave pública almacenada. Siempre que la firma sea válida, el servidor puede considerar que las marcas son originales.
En el registro y la autenticación de la llave de acceso, el servidor debe examinar que la marca UP sea true y si la marca UV es true o false, según el requisito.
Especifica el parámetro userVerification
Según la especificación de WebAuthn, el RP puede solicitar una verificación del usuario con un parámetro userVerification en la creación y la aserción de credenciales. Acepta 'preferred', 'required' o 'discouraged', que significa lo siguiente, respectivamente:
'preferred'(predeterminado): Se prefiere usar un método de verificación del usuario en el dispositivo, pero se puede omitir si no está disponible. La credencial de respuesta contiene un valor de marca UV detruesi se realizó la verificación del usuario yfalsesi no se realizó UV.'required': Es necesario invocar un método de verificación de usuario disponible en el dispositivo. Si no hay uno disponible, la solicitud fallará de forma local. Esto significa que la credencial de respuesta siempre se muestra con la marca UV establecida entrue.'discouraged': No se recomienda usar un método de verificación de usuarios. Sin embargo, según el dispositivo, es posible que se realice la verificación del usuario de todos modos, y el indicador de UV puede contenertrueofalse.
Código de muestra para la creación de llaves de acceso:
const publicKeyCredentialCreationOptions = {
// ...
authenticatorSelection: {
authenticatorAttachment: 'platform',
residentKey: 'required',
requireResidentKey: true,
userVerification: 'preferred'
}
};
const credential = await navigator.credentials.create({
publicKey: publicKeyCredentialCreationOptions
});
Código de muestra para la autenticación con llave de acceso:
const publicKeyCredentialRequestOptions = {
challenge: /* Omitted challenge data... */,
rpId: 'example.com',
userVerification: 'preferred'
};
const credential = await navigator.credentials.get({
publicKey: publicKeyCredentialRequestOptions
});
¿Qué opción elegirías para userVerification?
El valor userVerification que debes usar depende de los requisitos de tu aplicación y de la experiencia del usuario.
Cuándo usar userVerification='preferred'
Usa userVerification='preferred' si priorizas la experiencia del usuario sobre la protección.
Hay entornos en los que la verificación del usuario genera más fricción que protección. Por ejemplo, en macOS donde Touch ID no está disponible (porque el dispositivo no lo admite, está deshabilitado o el dispositivo está en modo clamshell), se le solicita al usuario que ingrese su contraseña del sistema. Esto genera inconvenientes, y es posible que el usuario abandone por completo la autenticación. Si eliminar la fricción es más importante, usa userVerification='preferred'.
Con userVerification='preferred', la marca de UV es true si la verificación del usuario se realiza correctamente y false si se omite. Por ejemplo, en macOS, donde Touch ID no está disponible, se le solicita al usuario que haga clic en un botón para omitir la verificación del usuario, y la credencial de clave pública incluye una marca de UV false.
La marca de UV puede ser un indicador en tu análisis de riesgos. Si el intento de acceso parece riesgoso debido a otros factores, te recomendamos que le presentes desafíos de acceso adicionales al usuario si no se realizó la verificación del usuario.
Cuándo usar userVerification='required'
Usa userVerification='required' si crees que UP y UV son absolutamente necesarios.
Una desventaja de esta opción es que el usuario puede experimentar más inconvenientes cuando accede. Por ejemplo, en macOS, donde Touch ID no está disponible, se le solicita al usuario que ingrese la contraseña del sistema.
Con userVerification='required', puedes asegurarte de que se realice la verificación del usuario en el dispositivo. Asegúrate de que el servidor verifique que la marca de UV sea true.
Conclusión
Con la verificación del usuario, las partes que dependen de llaves de acceso pueden medir las probabilidades de que el propietario del dispositivo acceda. Usted decide si exigir la verificación del usuario o hacerlo opcional según la importancia del mecanismo de acceso de resguardo en el flujo de usuarios. Asegúrate de que el servidor verifique la marca UP y la marca UV para la autenticación del usuario de la llave de acceso.