WebAuthn en la vida real

En septiembre de 2019, el equipo de Mail.ru Mail apoyó la tecnología WebAuthn. Nos convertimos en el primer servicio de correo electrónico del mundo que implementó la capacidad de iniciar sesión en su cuenta utilizando claves electrónicas en lugar de contraseñas. Ahora esta oportunidad está disponible para todos nuestros usuarios, puede vincular la clave electrónica a su cuenta en la configuración y luego usarla libremente para ingresar.



Nosotros ya escribimos noticias sobre este evento aquí, en Habré. En este artículo quiero hablar más sobre las razones para implementar WebAuthn en nuestros servicios y sobre los aspectos técnicos de trabajar con esta tecnología.

¿Qué es WebAuthn y por qué es necesario?


En el mundo moderno, la mayoría de los servicios de Internet usan contraseñas para autenticar a los usuarios. La ventaja de las contraseñas es su simplicidad: para acceder al recurso necesario solo necesita conocer la contraseña e ingresarla correctamente.

Sin embargo, las desventajas de las contraseñas a menudo superan sus ventajas:

  • si la contraseña es simple, puede recuperarla;
  • si se usa la misma contraseña en varios servicios, al romper uno de ellos, el atacante obtiene acceso a todos los demás;
  • las contraseñas son vulnerables a los ataques de phishing;
  • Las contraseñas seguras y únicas son difíciles de recordar, por lo que el usuario se ve obligado a escribir la contraseña en la etiqueta y pegarla en el monitor, desde donde se puede espiar, robar o perder fácilmente.

Para deshacerse de las deficiencias de las contraseñas y hacer que el proceso de autenticación sea más seguro, aparecen varias formas de reemplazar las contraseñas: este es el uso de códigos únicos que se envían al usuario a través de SMS o notificaciones PUSH, o el uso de aplicaciones especiales de generador de códigos TOTP con las que el usuario puede iniciar sesión cuenta sin ingresar su contraseña.

Empresas como Microsoft , Yahoo , Amazon piensan en usar métodos de autenticación sin contraseña y abandonan por completo el uso de contraseñas en sus servicios. Mail.ru mail no es una excepción, hemos respaldado el inicio de sesión utilizando códigos únicos, lo que permite a los usuarios no recordar contraseñas complejas y sólidas y acceder rápidamente a su cuenta.

Otra alternativa a las contraseñas es la autenticación mediante claves electrónicas (claves de seguridad, otro nombre: autenticadores electrónicos). El principio de su funcionamiento se basa en el uso de la criptografía asimétrica y se describe en la familia de protocolos FIDO2, desarrollada por la alianza FIDO (Fast IDentity Online).

En marzo de 2019, W3C lanzó la primera versión del estándar., que describe una API JS basada en navegador que le permite interactuar con claves electrónicas. El estándar recibió el estado de recomendación y el nombre Autenticación web: API para acceder a las credenciales mediante una clave pública: nivel uno (Autenticación web: una API para acceder al Nivel 1 de credenciales de clave pública), para abreviar, WebAuthn.

Cómo funciona WebAuthn


Se identifican los siguientes actores clave en el proceso de autenticación utilizando WebAuthn:

  • Cliente (Cliente WebAuthn): un navegador que admite la API WebAuthn;
  • Aplicación web: una aplicación que se ejecuta en el cliente utilizando la API de WebAuthn para interactuar con las credenciales;
  • credenciales (credencial de clave pública): un par de claves criptográficas públicas y privadas asociadas con una cuenta de usuario;
  • Authenticator, un dispositivo o programa, crea credenciales de usuario y firma las solicitudes de la parte que confía con estas credenciales (otro nombre es una clave electrónica);
  • la parte que confía (WebAuthn Relying Party), el servidor web, almacena la clave pública asociada con la cuenta de usuario, verifica la validez de la firma de sus solicitudes con la clave privada almacenada en el autenticador.

La API de WebAuthn le permite realizar solo dos operaciones. Le permite crear nuevas credenciales y firmar solicitudes del servidor con credenciales ya creadas.

Creación de credenciales ( MakeCredential )



Esquema del escenario con la creación de credenciales, tomado de w3.org .

En esta etapa, la clave electrónica se registra en la cuenta de usuario. Dentro del autenticador, se genera un nuevo par de claves públicas y privadas, y la clave pública se envía y almacena en la cuenta de usuario en el servidor.

const credential = await navigator.credentials.create({
    publicKey: publicKeyMakeCredentialOptions
});

Firmar una solicitud con credenciales ya creadas ( GetAssertion )



Esquema de la etapa con verificación de credenciales, tomado de w3.org .

En este paso, se verifica si el usuario tiene un autenticador cuya clave pública está almacenada en la cuenta del usuario. Un token aleatorio se firma con la clave privada dentro del autenticador y se envía al servidor, donde el servidor verifica que la firma sea correcta. En consecuencia, si la firma es correcta, concluimos que el usuario realmente tiene este autenticador.

const assertion = await navigator.credentials.get({
    publicKey: publicKeyGetAssertionOptions
});

Puede ver una demostración del proceso de ingresar Mail.ru Mail usando WebAuthn en este video .

Puede obtener más información sobre la API de WebAuthn en la especificación de WebAuthn y, por ejemplo, en este artículo de Medium .

Entonces, el trabajo de WebAuthn se basa en el uso de claves electrónicas. ¿Qué es?

Llaves electronicas


Las claves electrónicas (a veces las llamaré también "claves WebAuthn", clave de seguridad de seguridad) son dispositivos o programas que implementan protocolos de interacción FIDO2.

En la especificación de WebAuthn y en el nivel del hogar, todas las llaves electrónicas se clasifican en una de dos categorías:

  • claves independientes de la plataforma (autenticadores de itinerancia);
  • Autenticadores de plataforma

Las claves independientes de la plataforma son dispositivos físicos externos, como Yubikey de Yubico o Titan Security Key de Google. Por lo general, dichos autenticadores están conectados a la computadora o teléfono inteligente del usuario a través de USB, NFC o BLE. La comunicación con dichos dispositivos se lleva a cabo utilizando el protocolo especial CTAP (Protocolo de Cliente a Autenticador).

Para comenzar a trabajar con llaves electrónicas físicas, el usuario debe vincularlo una vez a su cuenta. Después de eso, el usuario tiene la oportunidad de usar esta clave electrónica para ingresar en cualquier otro dispositivo y en cualquier navegador.


Ejemplos de varias claves independientes de la plataforma, tomadas de theverge.com .

Si el mecanismo de operación del primer tipo de teclas es más o menos claro, entonces quiero profundizar en la segunda categoría.

En el segundo caso, las claves criptográficas públicas y privadas se generan y almacenan no dentro de un dispositivo físico externo, sino con algún módulo de software dentro de una computadora o teléfono inteligente. Este módulo de software puede implementarse en el nivel de aplicación específico o en el nivel del sistema operativo. Por ejemplo, en un chip seguro dentro de una computadora, a la cual su sistema operativo solo le dará acceso si está conectado y ha demostrado que realmente es usted.

En la mayoría de las implementaciones modernas en diferentes navegadores, el sistema operativo requiere que el usuario se confirme con una huella digital o ingresando la contraseña de la cuenta de usuario. Es importante aclarar que, aunque el usuario necesita poner su dedo en el escáner de huellas digitales para usar tales teclas, la huella digital en sí misma no se almacena en ningún lado y no se transmite a ningún lado. Esta es solo la forma en que el sistema operativo o el navegador validan al usuario.


Uso de autenticadores específicos de plataforma.

Solo la información de clave pública codificada o un token aleatorio firmado se devuelve al servicio web desde la API de WebAuthn, que luego se almacena y verifica en el lado del servidor.

Por lo tanto, en el caso del autenticador incorporado, será posible usarlo solo en el navegador y dispositivo donde estaba conectado a la cuenta. En otras palabras, las claves dependientes de la plataforma deberán registrarse por separado en cada dispositivo / navegador en el que intente iniciar sesión en su cuenta.

En el futuro, se espera que aparezcan más formas que permitirán al usuario activar el uso de autenticadores específicos de la plataforma, por ejemplo, mediante un escaneo facial o ingresando un código PIN desde el dispositivo.

Al crear credenciales o calcular la firma, puede especificar el tipo preferido de autenticador en un parámetro especial que toma dos valores, cross-platformy platform. En este caso, se le pedirá al usuario que use solo uno de los tipos de llaves electrónicas.

const credential = await navigator.credentials.create({
    publicKey: {
        authenticatorSelection: {
            authenticatorAttachment: 'cross-platform',
        },
        ...,
    },
});

Beneficios de WebAuthn


¿Cuáles son los beneficios de la tecnología WebAuthn para usuarios y desarrolladores?

  • El usuario no necesita recordar ni ingresar ninguna contraseña, y el servidor no almacena las contraseñas de los usuarios, respectivamente, todas las deficiencias que tenían las contraseñas desaparecieron. Robar un autenticador físico de un usuario es mucho más difícil que interceptar una contraseña transmitida electrónicamente a través de una conexión insegura, y una fuga de claves públicas en el sitio no abrirá la clave privada oculta en el dispositivo.
  • origin , . origin . , (thesslstore.com, yubico.com) .
  • WebAuthn - . - web- , .
  • El propio WebAuthn como API proporciona a los desarrolladores una abstracción sobre la implementación de autenticadores y le permite escribir código una vez, que luego funcionará con todos los tipos y tipos de claves electrónicas. Por lo tanto, WebAuthn es una solución escalable para la autenticación de usuarios.

Aún más sobre por qué WebAuthn es más seguro que una contraseña: WebAuthn para desarrolladores: 5 pasos para una mejor autenticación , Primeros pasos con las claves de seguridad .

Soporte WebAuthn


Si la autenticación de dongle funciona o no en su dispositivo depende de varios factores diferentes. Comenzando desde si su navegador admite la API de WebAuthn y terminando con qué conectores hay en su computadora y qué métodos de comunicación admite su autenticador. El rendimiento de WebAuthn también depende en gran medida del dispositivo y sistema operativo que utilice.

Al momento de escribir, de acuerdo con caniuse.com, la API de WebAuthn es compatible con el 80.5% de los usuarios. Según las estadísticas de los usuarios de Mail.ru, esta cifra tiene el mismo orden: 79.8%. Sin embargo, para utilizar WebAuthn en todos estos navegadores, definitivamente necesitará una clave electrónica externa.

No todos los navegadores que admiten la API de WebAuthn pueden funcionar con claves dependientes de la plataforma (para mayor comodidad, más adelante me referiré a estas claves como "huellas digitales"). Además, para trabajar con tales teclas, no es suficiente instalar un navegador que pueda funcionar con ellas. También es necesario que su dispositivo y sistema operativo tengan un módulo / sensor apropiado y puedan interactuar con él. De todos los usuarios de Mail.ru, solo el 9.0% tiene la capacidad de agregar claves específicas de la plataforma.

Te contaré brevemente sobre el soporte de WebAuthn por diferentes sistemas operativos y navegadores.

Ventanas


El soporte de WebAuthn en Windows es muy bueno. El subsistema de autenticación de Windows Hello puede funcionar con claves electrónicas. Por lo tanto, todas las versiones de navegador más recientes para este sistema operativo (Microsoft Edge, Google Chrome, Opera y Mozilla Firefox) admiten trabajar con claves externas y huellas digitales. Internet Explorer API WebAuthn no es compatible.


Linux


Los autenticadores externos generalmente son compatibles con cualquier distribución moderna de Linux, así como con navegadores como Google Chrome, Chromium y Mozilla Firefox. Sin embargo, en algunos sistemas se pueden requerir configuraciones adicionales para trabajar con claves foráneas .

Androide


El soporte de WebAuthn en Android también es bueno. Google Chrome, Opera y Mozilla Firefox: admiten trabajar con claves externas y huellas digitales. Pero Microsoft Edge para Android no es compatible con la API de WebAuthn. También hay un error en Firefox: especificar el tipo preferido de autenticador usando la opción no funciona para él authenticatorAttachment.


iOS


Entre todos los navegadores para el sistema operativo iOS, WebAuthn solo es compatible con Safari versión 13.3 móvil. Además, solo puede trabajar con llaves electrónicas externas. Otros navegadores para iOS aún no son compatibles con WebAuthn.

Mac OS


Microsoft Edge, Google Chrome, Opera y Mozilla Firefox admiten trabajar con claves externas en macOS. Google Chrome también admite huellas digitales, lo que le permite utilizar WebAuthn con Touch ID.


Si en Edge, Opera y Chrome la interfaz para interactuar con WebAuthn es la misma, entonces Firefox se ha distinguido aquí. En lugar de una bonita ventana emergente en Firefox, cuando usa WebAuthn, aparece una pequeña notificación en la esquina de la pantalla. Si accidentalmente hace clic en una página, simplemente se colapsa, dejando al usuario perdido en lo que está sucediendo ahora.



Sin embargo, Safari aún no ha admitido WebAuthn. El soporte de WebAuthn se anunció en Safari 13, que estará disponible en macOS 10.15 Catalina. Sin embargo, al momento de escribir, mis controles mostraron que la API de WebAuthn en Safari, aunque está presente, es extremadamente inestable y no funciona con todos los autenticadores. Al igual que su versión móvil, Safari no funciona con llaves electrónicas incorporadas. Además, todavía no admite ninguna de las claves electrónicas extranjeras.

Entonces, nos dimos cuenta de que, además de los problemas de soporte, WebAuthn tiene diferencias aún mayores en la interfaz de usuario. Estas diferencias conducen al hecho de que debe explicar con más detalle al usuario qué se requiere de él para utilizar la entrada a través de llaves electrónicas. Además, con cada nueva versión del navegador, estas ventanas emergentes pueden cambiar, y el proceso de usar WebAuthn hoy puede ser muy diferente de lo que era ayer.

Está claro por qué esto está sucediendo. La tecnología WebAuthn todavía es bastante joven, y los desarrolladores de navegadores aún están experimentando con diferentes tipos de implementación. Uno solo puede esperar que con el tiempo el soporte para WebAuthn en los navegadores se estabilice y podamos usarlo sin restricciones.

Registro de autenticador


Si le damos al usuario la oportunidad de registrar diferentes claves electrónicas en su cuenta, entonces debería tener la oportunidad de ver su lista y eliminar las obsoletas o innecesarias. Esto puede ser útil, por ejemplo, en caso de compromiso de una de las claves.

La API de WebAuthn está diseñada para que al crear y usar credenciales, el cliente no tenga disponible ninguna información sobre el tipo, tipo y nombre de los autenticadores utilizados. En consecuencia, no tenemos ningún dato por el cual podamos distinguir una clave de otra. Todas las claves de la lista se presentarán por igual sin distinguir características. Pregunta: que hacer


Puede obtener información sobre el autenticador utilizado si solicita las llamadas credenciales al crear credenciales. Certificación. La certificación es una forma para que un autenticador demuestre su autenticidad a un servidor. En algunos casos, la información sobre el fabricante clave se puede obtener de la certificación. Pero en el caso general, los datos utilizados aún no son suficientes para distinguir claramente una clave electrónica asociada con una cuenta de otra.

const credential = await navigator.credentials.create({
    publicKey: {
        attestation: 'direct',
         ...,
    },
});

Por lo tanto, después de conectar la clave a la cuenta en Mail, le damos al usuario la oportunidad de asignar algún nombre al registro recién creado. Y además, el usuario puede distinguir una clave de otra por este nombre.

El hecho de que la información disponible para el cliente y el servidor no contenga datos sobre el tipo de autenticador conduce a otra característica desagradable de WebAuthn.

Imagine un usuario que agregó solo una huella digital a su cuenta, por ejemplo, en su teléfono inteligente. Cuando deseamos iniciar sesión con la API de WebAuthn, pasamos una llamada de funciónnavigator.credentials.getlista de todas las claves asociadas a una cuenta. Pero el navegador no puede determinar de esta lista cuáles de los autenticadores están presentes en el dispositivo y cuáles no. Por lo tanto, se ve obligado a ofrecer siempre al usuario que use WebAuthn.

Por lo tanto, incluso cuando intente iniciar sesión en una cuenta en una computadora que no admite la autenticación a través de huellas dactilares, se le ofrecerá al usuario que use WebAuthn.

Para implementar el comportamiento correcto en tales situaciones, debe refinar el estándar WebAuthn. Por ejemplo, para codificar información sobre si se usó una clave multiplataforma o una huella digital para crearla y no para ofrecer al usuario de WebAuthn en los casos en que se sabe de antemano que no podrá usarla.

Hay formas de evitar este comportamiento en algunas situaciones. Por ejemplo, permita que el usuario registre huellas digitales y claves físicas solo individualmente. Y cuando use teclas, filtre las huellas digitales en dispositivos que obviamente no las admiten. Pero este método no resuelve el problema por completo. Y no hay una forma confiable de resolver este problema.

Nuestros usuarios aún no han recibido quejas sobre este comportamiento, por lo que actualmente estamos investigando esta característica y decidiendo qué hacer en el futuro.

WebAuthn funciona en diferentes subdominios


Como dije anteriormente, WebAuthn brinda protección inmediata contra el phishing. Al registrar claves electrónicas, se almacena información originen la que se registró esta clave. WebAuthn no permite el uso de esta clave electrónica en recursos, con otra origin.

Los grandes servicios web como Mail.ru a menudo usan varios dominios diferentes para su trabajo. Por ejemplo, tenemos un dominio e.mail.rupara Correo y cloud.mail.rupara la Nube. Y en cada uno de ellos tenemos una forma común de autorización. En este caso, la configuración estándar de WebAuthn no es suficiente. Para que podamos usar originclaves registradas en el otro en uno origin, es necesario que estos dos dominios tengan un sufijo común (un subdominio común de más del primer nivel).

Por ejemplo en dominiose.mail.ruy el cloud.mail.rusufijo común es mail.ru.

En este caso, al registrar y usar claves electrónicas, podemos especificar un parámetro rpIdigual en las opciones de solicitud mail.ru, y luego podemos usar la misma clave en la subclave misma https://mail.ruy en cualquiera de sus subdominios.

const credential = await navigator.credentials.create({
    publicKey: {
        rp: {
            name: 'Mail.ru Group',
            id: 'mail.ru',
        },
        ...,
    },
});

WebAuthn trabaja en iframe


Por razones de seguridad, las llamadas a los métodos WebAuthn están prohibidas desde iframes de origen cruzado. Nuestros proyectos utilizan un solo formulario de autorización, se encuentra en https://account.mail.ru/login , y cuando queremos mostrar el formulario de autorización en cualquier otro proyecto, por ejemplo, en Mail o en la nube, el iframe se agrega a la página dentro del cual se abre esta url. Esta solución nos permite actualizar simultáneamente el formulario en todos los proyectos que lo usan, y simplifica la recopilación de estadísticas, y también mejora la UX del usuario, permitiéndole permanecer en el mismo servicio donde estaba originalmente.



En nuestro caso, la restricción en las llamadas a los métodos de WebAuthn desde dentro del iframe nos hizo buscar formas de evitarlo, porque queríamos dar la oportunidad de iniciar sesión a través de WebAuthn en cualquier lugar donde mostramos el formulario de autorización.

Qué hemos hecho. Para abrir el formulario de autorización en todos los servicios, utilizamos una pequeña biblioteca, que esencialmente solo crea un iframe en la página con la URL correcta y después de cargar su contenido muestra el iframe en la página. Esta biblioteca admite la comunicación con iframes postMessagey la utiliza, por ejemplo, para cambiar el tamaño de los iframes al cambiar el tamaño de sus contenidos.

Se nos ocurrió e implementamos el siguiente mecanismo:

  1. en la aplicación de autorización cuando se usa WebAuthn, determinamos si ahora estamos abiertos dentro del iframe o no;
  2. si estamos abiertos dentro del iframe, entonces en lugar de llamar al API WebAuthn del navegador, serializamos los parámetros de la llamada y los enviamos a través de la postMessageventana principal;
  3. en la ventana principal deserializamos estos parámetros y llamamos a los métodos WebAuthn;
  4. cuando recibimos una respuesta, la serializamos de la misma manera y la enviamos a través del postMessageinterior de un iframe, donde aceptamos esta respuesta y realizamos un procesamiento adicional.

Por lo tanto, eludimos esta prohibición y nos dimos cuenta de la posibilidad de utilizar la misma clave durante la autorización en todos los servicios de la empresa.

WebAuthn Test Automation


En nuestro equipo para todos los nuevos proyectos y características, siempre escribimos autotests de integración de UI utilizando soluciones similares al selenio y el protocolo WebDriver. Por lo tanto, durante el desarrollo de WebAuthn, surgió la pregunta de cómo escribir la interfaz de usuario de autotests en él.

La dificultad para escribir estas pruebas automáticas es que el protocolo WebDriver aún no tiene métodos para automatizar la interacción con WebAuthn. Y en el estándar en sí todavía no hay soporte para probar la automatización de API WebAuthn (pero hay un problema sobre este tema). Las primeras ideas sobre cómo se puede organizar esta automatización se describen en un borrador de Autenticación web: una API para acceder al Nivel 2 de credenciales de clave pública y aún no se han publicado, sin mencionar que se admite en otros lugares. Por lo tanto, tuve que encontrar soluciones alternativas.

Porque no podemos trabajar con la implementación nativa de las funciones de WebAuthn en las pruebas automáticas (no hay métodos para controlar el navegador), luego tuvimos que hacer lo siguiente.

En algún lugar de la prueba automática, antes de intentar usar WebAuthn, aplicamos parches a los objetos de host globales del navegador y reemplazamos las funciones nativas con nuestras implementaciones. Aquí guardamos los argumentos con los que las funciones nativas fueron llamadas a una variable y devolvemos la promesa.

//    WebAuthn   
navigator.credentials.create = (options) => {
    window.credentialsCreateArgs = options;

    return new Promise((resolve, reject) => {
        window.credentialsCreateSuccess = resolve;
        window.credentialsCreateFail = reject;
    });
};

A continuación, necesitamos obtener de alguna manera el resultado de la función para devolverlo y emular el trabajo de WebAuthn en las pruebas. Siempre podemos devolver algún tipo de respuesta codificada constante.

// -    
const credentialsCreateResponse = { /* constant object */ };

window.credentialsCreateSuccess(credentialsCreateResponse);

En este caso, tendremos que enseñarle a nuestro servidor a aceptar esta respuesta y no validarla, pero considerarla automáticamente correcta.

¿Cuáles son las desventajas de tales pruebas? En este caso, no podremos:

  • compruebe si el cliente forma y enrolla los parámetros correctamente en las funciones de WebAuthn;
  • verifique la corrección de los cambios de backend cuando se ejecutan lanzamientos de backend.

Por lo tanto, tales pruebas no serán lo suficientemente confiables, y esto no nos conviene.

Decidimos ir por el camino más difícil y eventualmente escribimos nuestra propia implementación de protocolos y algoritmos FIDO2 en Node.js, con lo que logramos bloquear estas funciones lo más cerca posible de las implementaciones nativas.

Es decir, escribimos una función que, en función de los parámetros de solicitud, calcula la respuesta para las funciones bloqueadas de WebAuthn para que el servidor considere que es completamente correcta.

// -    
const credentialsCreateResponse =
    calcCredentialsCreateResponse(window.credentialsCreateArgs);
 
window.credentialsCreateSuccess(credentialsCreateResponse);

Como resultado, el esquema de operación de autotest es el siguiente:

  1. obtener los argumentos con los que se llamaron los métodos WebAuthn;
  2. ejecutamos estos argumentos a través de una función que implementa los mismos algoritmos que dentro de los autenticadores reales;
  3. obtenemos el resultado y lo devolvemos de nuestras funciones reemplazadas;
  4. todo el resto del código en nuestro servicio procesa estas respuestas en el modo habitual y, como resultado, todo el comportamiento del servicio no difiere de su comportamiento para usuarios reales.

Las fuentes de este autotest y la implementación del autenticador más encubierto están en el repositorio de github , puede comenzar e investigar su trabajo más adelante. Al escribir el autenticador, nos guiamos solo por la especificación w3.org y la documentación de Node.js.

El presente y el futuro de WebAuthn


Entonces, lo que tenemos en este momento.

Lanzamos una entrada de clave electrónica totalmente funcional a finales de septiembre de 2019. Ahora no publicitamos este tipo de entrada, y no se usa de manera muy activa: menos de cien usuarios únicos por día. Pero estamos seguros de que con el tiempo su número solo crecerá, y tarde o temprano, el registro de clave electrónica se convertirá en uno de los principales tipos de inicio de sesión en su cuenta.

Lo que nos impide promover activamente una entrada de este tipo es que WebAuthn en sí mismo todavía no es lo suficientemente confiable y estable en los navegadores, y hay muchos matices con respecto a su soporte y operación.

¿Por qué WebAuthn ahora es una característica que no es para una audiencia amplia?

El factor más básico aquí es que requiere que el usuario tenga un dispositivo especial: una llave electrónica. Ahora la necesidad de esto no es tan aguda para los usuarios. Muchos usuarios no son conscientes de su existencia. Pero con el tiempo, cuando más y más servicios comiencen a admitir esta forma de inicio de sesión, la cantidad de usuarios con esas claves también comenzará a crecer.

Un salto significativo en la popularidad de WebAuthn puede ocurrir cuando los ingenieros de Google completan el desarrollo y las pruebas de la posibilidad de usar teléfonos inteligentes en el sistema operativo Android e iOS como claves electrónicas físicas externas para WebAuthn y abren esta oportunidad para todos los servicios de Internet. En este caso, cada propietario de un teléfono inteligente moderno esencialmente tendrá la oportunidad de usarlo como una clave de WebAuthn y la cantidad de usuarios de WebAuthn aumentará dramáticamente. Ahora esta función solo está disponible para los usuarios del servicio de correo electrónico de Google.



¿De qué otra forma puedes usar WebAuthn?


Mail.ru usa WebAuthn ahora como una alternativa a las contraseñas para ingresar a la cuenta. Pero esencialmente WebAuthn puede usarse como cualquiera de los factores de autorización. Se puede usar como lugar del primer factor en la autenticación de un factor. Entonces, en lugar de la segunda, como una protección de contraseña adicional con dos factores. Además, la confirmación a través de una clave electrónica se puede utilizar, por ejemplo, al restaurar el acceso a una cuenta si el usuario ha perdido u olvidado su contraseña.

WebAuthn se puede usar como una medida de seguridad adicional al editar configuraciones críticas de su cuenta. Imagine lo conveniente que es: ¡vaya a la configuración del perfil en su servicio favorito y no necesita recordar ni ingresar una contraseña para cambiarlos! Simplemente coloque el dedo en el escáner de huellas digitales y se le transmitirá.

Puede encontrar escenarios aún más diferentes para usar WebAuthn en este artículo de Medium .

Preguntas y respuestas populares


¿Dónde puedo comprar una llave electrónica?


Hasta ahora, no hay muchos lugares en Rusia donde pueda comprar llaves electrónicas compatibles con los protocolos FIDO2. La mayoría de los proveedores solo los venden a granel, en lotes de 10 o más. Puedes comprar llaves electrónicas pieza por pieza en las siguientes tiendas:


Además, dichas llaves se pueden pedir en tiendas en línea amigables, por ejemplo, en Amazon . En este artículo, hay características comparativas de los interruptores electrónicos de 10 modelos con enlaces a tiendas donde se pueden comprar.

¿Qué pasa si pierdo mi llave electrónica?


Con las llaves electrónicas, debe tratarlas con la misma atención que con las llaves del apartamento o automóvil. Si perdemos las llaves del apartamento, generalmente cambiamos la cerradura y obtenemos nuevas llaves. Lo mismo ocurre con las claves electrónicas: si se pierden, debe eliminarlas inmediatamente de todas las cuentas donde estaban vinculadas y adjuntar un nuevo autenticador a todas las cuentas.

En caso de pérdida de la clave electrónica principal, debe tener varios métodos de autenticación adicionales. Por ejemplo, usando la aplicación para generar códigos, o usando una llave de repuesto que se puede almacenar en un lugar especialmente protegido: en una caja fuerte o en una celda del banco.

¿Qué debo hacer si alguien más tiene acceso a mi llave electrónica?


Si la autenticación de dos factores está incluida en su cuenta y la clave electrónica es solo uno de los factores, en este caso su cuenta estará protegida contra piratería. A menos que el atacante tenga acceso al segundo factor.

Si la clave electrónica es el único factor suficiente para ingresar a la cuenta, incluso en este caso el atacante debe saber el nombre de la cuenta en la que está registrada esta clave electrónica. Esta información no se almacena dentro de la clave electrónica y, por lo tanto, una clave electrónica perdida accidentalmente con un alto grado de probabilidad será completamente inútil para un transeúnte que la encontró.

Sin embargo, existen esquemas en los que las claves electrónicas se pueden usar como reemplazo no solo de una contraseña, sino también de un inicio de sesión. En este escenario, el servidor solo proporciona credenciales cuando solicita credenciales.origin, y las credenciales mismas se almacenan por completo en el autenticador. En este caso, la clave electrónica perdida ya se puede usar fácilmente para ingresar a su cuenta, y luego debe tener más cuidado con su autenticador. Para protección en tales escenarios, puede usar llaves electrónicas con medidas de seguridad adicionales, por ejemplo, llaves, para la activación de las cuales debe ingresar un código PIN.

En cualquier caso, tan pronto como note la pérdida de su clave, debe desatarla inmediatamente de todas las cuentas en todos los servicios, donde puede usarla para ingresar. Es por eso que todos los servicios deberían proporcionar la capacidad de administrar una lista de autenticadores vinculados. Cuanto más rápido note la pérdida, menos tiempo tendrán los atacantes para obtener acceso a sus datos.

¿Ahora mis datos biométricos se almacenarán en los servidores Mail.ru/Google/Microsoft?


Cuando WebAuthn trabaja con autenticadores integrados (por ejemplo, usando Touch ID en Mac OS), solo el sensor correspondiente y el sistema operativo tienen acceso a sus datos biométricos. El servicio web no recibe ni procesa ninguna información biométrica; solo funciona con la clave criptográfica pública y con los datos firmados con la clave privada.

Y en el servidor mismo, solo se almacena información sobre la clave pública. Por lo tanto, WebAuthn no utiliza sus datos biométricos de ninguna manera para trabajar con autenticadores integrados.

Conclusión


Como descubrimos, WebAuthn tiene muchas ventajas importantes sobre las contraseñas:

  • cuando se usa WebAuthn no es necesario recordar e ingresar contraseñas;
  • WebAuthn - , ;
  • WebAuthn ;
  • WebAuthn — .

Sin embargo, las contraseñas no deben descartarse. Todavía se puede robar o perder una clave física, como una contraseña. Pero las contraseñas tienen una ventaja importante. Mientras se almacenen solo en la cabeza, no funcionará conocerlos sin el conocimiento del propietario.

En resumen, quiero decir que la tecnología WebAuthn es una tecnología muy prometedora que cambia un elemento tan básico e importante del funcionamiento de todos los servicios web modernos como la autenticación. También es una tecnología bastante joven y los usuarios aún no están acostumbrados. Pero está en nuestro poder hacerlo más popular y conveniente.

Espero que nuestra experiencia de implementar WebAuthn en Mail.ru Mail lo ayude a respaldarlo en sus servicios, y juntos haremos que Internet sea más seguro y moderno.

Materiales adicionales



All Articles