Estas cosas llamadas Passkeys ya están circulando hoy en día. Fueron una atracción principal en W3C TPAC 2022, obtuvieron soporte en Safari 16, se están abriendo camino en macOS e iOS y están programadas para ser el futuro de los administradores de contraseñas como 1Password. Ya son compatibles con Android y pronto llegarán a Chrome OS y Windows en futuras versiones.

Las mejoras de seguridad del sistema operativo Geeky no acaparan grandes titulares en la comunidad de front-end, pero es lógico que las Passkeys vayan a ser algo importante. Y considerando cómo las contraseñas y las aplicaciones de contraseñas afectan la experiencia del usuario en cosas como la autenticación y el procesamiento de formularios, es posible que al menos queramos comprenderlas para saber lo que viene.

 

Terminología

Aquí está la sección obligatoria de la terminología que querrá saber a medida que profundizamos. Como la mayoría de la tecnología, las Passkeys están elaboradas con verborrea esotérica y acrónimos que a menudo son obstáculos para la comprensión. Intentaremos desmitificar varios aquí.

  • Relying Party:  el servidor en el que se autenticará. Usaremos «servidor» para referirnos a la parte que confía en este artículo.
  • Client:  en nuestro caso, el navegador web o sistema operativo.
  • Authenticator:  Dispositivos de software y/o hardware que permiten la generación y almacenamiento de pares de claves públicas.
  • FIDO : Organismo de estándares abiertos que también crea especificaciones en torno a las credenciales FIDO.
  • WebAuthn : el protocolo subyacente para las Passkeys, también conocido como  credencial FIDO2  o credenciales FIDO de dispositivo único.
  • Passkeys : WebAuthn, pero con sincronización en la nube (también llamadas credenciales FIDO multidispositivo, credenciales reconocibles o credenciales residentes).
  • Public Key Cryptography:  un par de claves generadas que incluye una clave pública y una privada. Dependiendo del algoritmo, debe usarse para firmar y verificar o para cifrar y descifrar. Esto también se conoce como  criptografía asimétrica .
  • RSA:  Acrónimo de los nombres de los creadores, Rivest Shamir y Adel. RSA es una familia de criptografía de clave pública más antigua, pero aún útil, basada en factorización de números primos.
  • Elliptic Curve Cryptography (ECC):  una familia más nueva de criptografía  basada en curvas elípticas .
  • ES256:  una clave pública de curva elíptica que utiliza un algoritmo de firma ECDSA ( PDF ) con  SHA256  para hash.
  • RS256:  Como ES256, pero usa RSA con  RSASSA-PKCS1-v1.5  y SHA256.

 

¿Qué son las Passkeys?

Antes de que podamos hablar específicamente sobre Passkeys, debemos hablar de otro protocolo llamado WebAuthn (también conocido como FIDO2). Las Passkeys son una especificación construida sobre WebAuthn. WebAuthn permite que la criptografía de clave pública reemplace las contraseñas. Utilizamos algún tipo de dispositivo de seguridad, como una clave de hardware o un Módulo de plataforma segura (TPM), para crear claves públicas y privadas.

La clave pública es para que cualquiera pueda usarla. Sin embargo, la clave privada no se puede eliminar del dispositivo que la generó. Este fue uno de los problemas con WebAuthn; si pierde el dispositivo, pierde el acceso.

Las Passkeys resuelven esto proporcionando una sincronización en la nube de sus credenciales. En otras palabras, lo que genera en su computadora ahora también se puede usar en su teléfono (aunque, de manera confusa, también hay credenciales para un solo dispositivo).

Actualmente, al momento de escribir este artículo, solo iOS, macOS y Android brindan soporte completo para Passkeys sincronizadas en la nube, e incluso así, están limitadas por el navegador que se utiliza. Google y Apple proporcionan una interfaz para la sincronización a través de sus  servicios Google Password Manager y Apple iCloud Keychain, respectivamente.

 

¿Cómo reemplazan las Passkeys a las contraseñas?

En criptografía de clave pública se puede realizar lo que se conoce como firma . La firma toma un dato y luego lo ejecuta a través de un algoritmo de firma con la clave privada, donde luego se puede verificar con la clave pública.

Cualquiera puede generar un par de claves públicas y no es atribuible a ninguna persona, ya que cualquiera podría haberlo generado en primer lugar. Lo que lo hace útil es que sólo los datos firmados con la clave privada se pueden verificar con la clave pública. Esa es la parte que reemplaza una contraseña: un servidor almacena la clave pública y nosotros iniciamos sesión verificando que tenemos la otra mitad (por ejemplo, la clave privada), firmando un desafío aleatorio.

Como beneficio adicional, dado que almacenamos las claves públicas del usuario dentro de una base de datos, ya no hay preocupación por las violaciones de contraseñas que afectan a millones de usuarios. Esto reduce el phishing, las infracciones y una serie de otros problemas de seguridad que enfrenta actualmente nuestro mundo dependiente de las contraseñas. Si se viola una base de datos, todo se almacena en las claves públicas del usuario, lo que la hace prácticamente inútil para un atacante.

¡Tampoco más correos electrónicos olvidados y sus contraseñas asociadas! El navegador recordará qué credenciales utilizó para cada sitio web; todo lo que necesita hacer es hacer un par de clics y habrá iniciado sesión. Puede proporcionar un medio secundario de verificación para usar la clave de acceso, como datos biométricos o un pin. , pero siguen siendo mucho más rápidas que las contraseñas de antaño.

 

Más sobre criptografía

La criptografía de clave pública implica tener una clave pública y una privada (conocida como par de claves). Las claves se generan juntas y tienen usos separados. Por ejemplo, la clave privada debe mantenerse en secreto y la clave pública está destinada a quien desee intercambiar mensajes.

Cuando se trata de cifrar y descifrar un mensaje, la clave pública del destinatario se utiliza para cifrar un mensaje de modo que solo la clave privada del destinatario pueda descifrar el mensaje. En el lenguaje de seguridad, esto se conoce como «brindar confidencialidad». Sin embargo, esto no proporciona prueba de que el remitente es quien dice ser, ya que cualquiera puede usar una clave pública para enviarle a alguien un mensaje cifrado.

Hay casos en los que necesitamos verificar que un mensaje efectivamente proviene de su remitente. En estos casos, utilizamos la firma y la verificación de firma para garantizar que el remitente sea quien dice ser (también conocido como  autenticidad ). En la criptografía de clave pública (también llamada  asimétrica ), esto generalmente se hace firmando el hash de un mensaje, de modo que solo la clave pública pueda verificarlo correctamente. El hash y la clave privada del remitente producen una firma después de ejecutarla a través de un algoritmo, y luego cualquiera puede verificar que el mensaje proviene del remitente con la clave pública del remitente.

 

¿Cómo accedemos a las Passkeys?

Para acceder a las Passkeys, primero debemos generarlas y almacenarlas en algún lugar. Algunas de estas funciones se pueden proporcionar con un autenticador. Un  autenticador  es cualquier dispositivo respaldado por hardware o software que brinda la capacidad de generar claves criptográficas. Piense en esas contraseñas de un solo uso que obtiene de Google Authenticator, 1Password o LastPass , entre otros.

Por ejemplo, un autenticador de software puede utilizar el Módulo de plataforma segura (TPM) o el enclave seguro de un dispositivo para crear credenciales. Luego, las credenciales se pueden almacenar de forma remota y sincronizar entre dispositivos, por ejemplo, Passkeys. Un autenticador de hardware sería algo así como  YubiKey , que puede generar y almacenar claves en el propio dispositivo.

Para acceder al autenticador, el navegador debe tener acceso al hardware y, para ello, necesitamos una interfaz. La interfaz que utilizamos aquí es el Protocolo de cliente a autenticador (CTAP). Permite el acceso a diferentes autenticadores a través de diferentes mecanismos. Por ejemplo, podemos acceder a un autenticador a través de NFC, USB y Bluetooth utilizando CTAP.

Una de las formas más interesantes de utilizar Passkeys es conectando su teléfono a través de Bluetooth a otro dispositivo que podría no admitir Passkeys. Cuando los dispositivos están emparejados a través de Bluetooth, puedo iniciar sesión en el navegador de mi computadora usando mi teléfono como intermediario.

 

La diferencia entre Passkeys y WebAuthn

Las Passkeys y las claves WebAuthn se diferencian en varios aspectos. En primer lugar, las Passkeys se consideran credenciales multidispositivo y se pueden sincronizar entre dispositivos. Por el contrario, las claves WebAuthn son credenciales de un solo dispositivo, una forma elegante de decir que está vinculado a un dispositivo para su verificación.

En segundo lugar, para autenticarse en un servidor, las claves WebAuthn deben proporcionar el identificador de usuario para iniciar sesión, después de lo cual  allowCredentials se devuelve una lista al cliente desde el servidor, que informa qué credenciales se pueden usar para iniciar sesión.  Las Passkeys omiten este paso y usan la nombre de dominio del servidor para mostrar qué claves ya están vinculadas a ese sitio.  Puede seleccionar la clave de acceso asociada con ese servidor, tal como ya la conoce su sistema.

De lo contrario, las claves son criptográficamente las mismas; sólo difieren en cómo se almacenan y qué información utilizan para iniciar el proceso de inicio de sesión.

 

El proceso… en pocas palabras

El proceso para generar un WebAuthn o una clave de acceso es muy similar: obtenga un desafío del servidor y luego use la  navigator.credentials.create API web para generar un par de claves públicas. Luego, envíe el desafío y la clave pública al servidor para almacenarlos.

Al recibir la clave pública y el desafío, el servidor valida el desafío y la sesión desde la cual fue creado. Si esto es así, la clave pública se almacena, así como cualquier otra información relevante como el identificador del usuario o los datos de certificación, en la base de datos.

El usuario tiene un paso más: recuperar otro desafío del servidor y usar la  navigator.credentials.get API para firmar el desafío. Enviamos el desafío firmado al servidor, y el servidor verifica el desafío y luego inicia sesión si se aprueba la firma.

Por supuesto, hay mucho más en cada paso. Pero así es generalmente como iniciamos sesión en un sitio web usando WebAuthn o Passkeys.

 

Manos a la obra…

Las Passkeys se utilizan en dos fases distintas: las  fases de certificación y afirmación .

La fase de certificación también puede considerarse como la fase de registro. Te registrarías con un correo electrónico y una contraseña para un nuevo sitio web; sin embargo, en este caso, usaríamos nuestra clave de acceso.

La fase de afirmación es similar a cómo iniciarías sesión en un sitio web después de registrarte.

 

Certificación

 

La  navigator.credentials.create API es el foco de nuestra fase de certificación. Estamos registrados como un nuevo usuario en el sistema y necesitamos generar un nuevo par de claves públicas. Sin embargo, debemos especificar qué tipo de par de claves queremos generar. Eso significa que debemos brindar opciones para  navigator.credentials.create.

Obtendremos  PublicKeyCredential cuál contiene un  AuthenticatorAttestationResponse que regresa después de la creación. La credencial tiene el ID del par de claves generado.

La respuesta proporciona un par de datos útiles. Primero, tenemos nuestra clave pública en esta respuesta y debemos enviarla al servidor para que la almacene. En segundo lugar, también recuperamos la  clientDataJSON propiedad que podemos decodificar y, a partir de ahí, recuperamos los caracteres  type,  challengey  origin de la clave de acceso.

Para la certificación, queremos validar  type,  challengey  origin en el servidor, así como almacenar la clave pública con su identificador, por ejemplo, niño. Opcionalmente también podemos almacenar el  attestationObject si lo deseamos. Otra propiedad útil para almacenar es el  algoritmo COSE  , que se define anteriormente en nuestro   PublicKeyCredentialCreationOptions with  alg: -7 o  alg: -256, para verificar fácilmente cualquier desafío firmado en la fase de afirmación.

 

Afirmación

La  navigator.credentials.get API será el foco de la fase de afirmación. Conceptualmente, aquí sería donde el usuario inicia sesión en la aplicación web después de registrarse.

Esta vez volveremos a tener un  PublicKeyCredential con un . AuthenticatorAssertionResponseLa credencial nuevamente incluye el identificador de clave.

También obtenemos  type,  challengey  origin de  clientDataJSON nuevo. El  signature ahora está incluido en la respuesta, así como el authenticatorData. Los necesitaremos y para  clientDataJSON verificar que esto se firmó con la clave privada.

Incluye  authenticatorData algunas propiedades que vale la pena rastrear. Primero, el hash SHA256 del origen que estás usando, ubicado dentro de los primeros 32 bytes, que es útil para verificar que la solicitud proviene del mismo servidor de origen. El segundo es el  signCount, que va del byte 33 al 37. Esto se genera a partir del autenticador y debe compararse con su valor anterior para garantizar que no ocurra nada sospechoso con la clave. El valor siempre debe ser 0 cuando se trata de una clave de acceso para múltiples dispositivos y debe ser aleatoriamente mayor que el signCount anterior cuando se trata de una clave de acceso para un solo dispositivo.

Una vez que haya afirmado su inicio de sesión, debería iniciar sesión: ¡  felicidades ! Passkeys es un protocolo bastante bueno, pero viene con algunas advertencias.

 

Algunas desventajas

Las Passkeys tienen muchas ventajas, sin embargo, existen algunos problemas al momento de escribir este artículo. Por un lado, las Passkeys todavía son un poco tempranas en cuanto a soporte, ya que solo se permiten credenciales de un solo dispositivo en Windows y muy poco soporte para sistemas Linux.  Passkeys.dev  proporciona una  buena tabla que es algo así como el Caniuse de este protocolo .

Además, las plataformas de Passkeys de Google y Apple no se comunican entre sí. Si desea transferir sus credenciales de su teléfono Android a su iPhone… bueno, por ahora no tiene suerte. ¡Eso no quiere decir que no haya interoperabilidad! Puede iniciar sesión en su computadora usando su teléfono como autenticador. Pero sería mucho más limpio tenerlo integrado en el sistema operativo y sincronizado sin que esté bloqueado a nivel de proveedor.

 

¿Adónde van las cosas?

¿Cómo será el protocolo de Passkeys del futuro? ¡Se ve bastante bien! Una vez que obtenga soporte de más sistemas operativos, debería haber una aceptación en su uso, y comenzarás a verlo usado cada vez más en la naturaleza. Algunos administradores de contraseñas incluso los respaldarán de primera mano.

Las Passkeys no solo se admiten en la web.  Tanto Android  como  iOS  admitirán claves nativas como ciudadanos de primera clase. Todavía estamos en los primeros días de todo esto, pero esperamos verlo mencionado cada vez más.

Después de todo, eliminamos la necesidad de contraseñas y, al hacerlo, ¡hacemos que el mundo sea más seguro!

 

Recursos

Aquí hay algunos recursos más si deseas obtener más información sobre las Passkeys.

 

 336 total views,  2 views today