Teclas de acceso: ¿Qué diablos y por qué? | trucos CSS

Estas cosas se llaman contraseñas sin duda están dando vueltas en estos días. Eran una gran atracción en W3C TPAC 2022 recibido apoyo en Safari 16  encontrar su camino en macOS y iOS y se prevé que sean el futuro de los administradores de contraseñas como 1Password.Ellos son ya es compatible en Android y pronto llegará a Chrome OS y Windows en versiones futuras.

Las mejoras de seguridad de Geeky OS no están generando grandes titulares en la comunidad front-end, pero tiene sentido que las claves de paso sean una "cosa". podría querer al menos pensar en ellos para que sepamos lo que viene.

Ese es el punto de este artículo. He estado estudiando y experimentando con contraseñas, y la API de WebAuthn en la que se basan, desde hace un tiempo. Déjame compartir lo que aprendí.

Terminología

Aquí está la terminología imprescindible que querrá saber a medida que nos adentramos en ella. Como la mayoría de las tecnologías, las claves de acceso se falsifican con frases esotéricas y siglas que muchas veces dificultan la comprensión. Voy a tratar de desmitificar algunos para usted aquí.

• Parte que confía: el servidor en el que se autenticará Usaremos "servidor" para referirnos a la Parte que confía en este artículo.
• Cliente: En nuestro caso, el navegador web o el sistema operativo.
• Autenticador: Dispositivos de software y/o hardware que permiten la generación y el almacenamiento de pares de claves públicas.
• FIDO: un organismo de estándares abiertos que también crea especificaciones en torno a las credenciales FIDO.
• WebAuthn: El protocolo de contraseña básico, también conocido como FIDO2 credenciales o credenciales FIDO para un solo dispositivo.
• Teclas de acceso: WebAuthn pero con sincronización en la nube (también denominadas credenciales FIDO multidispositivo, credenciales detectables o credenciales residentes).
• Criptografía de clave pública: Un par de claves generado que incluye una clave pública y una privada. Según el algoritmo, debe usarse para firmar y verificar o para cifrar y descifrar. Esto también se conoce como criptografía asimétrica.
• RSA: Un acrónimo de los nombres de los creadores, Rivest Shamir y Adel RSA es una familia antigua pero aún útil de criptografía de clave pública basada en la descomposición de números primos.
• Criptografía de curva elíptica (ECC): Una nueva familia de criptografía basado en curvas elípticas.
• ES256: Una clave pública de curva elíptica que utiliza el 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 contraseñas?

Antes de que podamos hablar específicamente sobre contraseñas, debemos hablar sobre otro protocolo llamado WebAuthn (también conocido como FIDO2). Las claves de acceso son una especificación que se basa en 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 llave de hardware o Modulo de plataforma confiable (TPM), para generar claves privadas y públicas.

La clave pública puede ser utilizada por cualquier persona. Sin embargo, la clave privada no puede ser eliminada por el dispositivo que la generó. Este fue uno de los problemas con WebAuthn; si pierde el dispositivo, pierde el acceso.

Passkeys soluciona este problema proporcionando sincronización en la nube de sus credenciales. En otras palabras, lo que genera en su computadora ahora se puede usar en su teléfono (confusamente, también hay credenciales de un solo dispositivo).

Actualmente, al momento de escribir este artículo, solo iOS, macOS y Android brindan soporte completo para contraseñas sincronizadas en la nube, e incluso entonces están limitadas por el navegador en uso. Google y Apple brindan una interfaz de sincronización a través de su Administrador de contraseñas de Google y Llavero Apple iCloud servicios, resp.

¿Cómo reemplazan las contraseñas las claves de acceso?

En la criptografía de clave pública, puede realizar lo que se conoce como firmar.Signing 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 se puede atribuir a ninguna persona, ya que cualquier persona podría haberlo generado en primer lugar. Lo que lo hace útil es que solo los datos firmados con la clave privada pueden verificarse con la clave pública. reemplaza una contraseña: el servidor almacena la clave pública e iniciamos sesión verificando que tenemos la otra mitad (por ejemplo, clave privada) firmando un desafío aleatorio.

Como beneficio adicional, dado que almacenamos las claves públicas del usuario en una base de datos, ya no existe la preocupación de que las violaciones de contraseñas afecten millones de usuarios. Esto reduce el phishing, las infracciones y una serie de otros problemas de seguridad que nuestro mundo dependiente de contraseñas Si se infringe una base de datos, todo se almacena en las claves públicas del usuario, haciéndola prácticamente inútil para un atacante.

¡No más correos electrónicos olvidados y contraseñas asociadas! El navegador recordará qué credenciales usó para qué sitio web: todo lo que tiene que hacer es hacer unos pocos clics e iniciar sesión. Puede proporcionar un medio de verificación secundario para usar una contraseña, como datos biométricos o un PIN, pero aún son mucho más rápidos que las contraseñas de ayer.

Más sobre criptografía

La criptografía de clave pública implica la presencia de una clave pública y una privada (conocidas como pares de claves). Las claves se generan juntas y tienen diferentes usos. Por ejemplo, la clave privada está destinada a mantenerse en secreto y la clave pública está destinada a cualquier persona con la que desee intercambiar mensajes.

Cuando se trata de cifrar y descifrar un mensaje, la clave pública del destinatario se usa para cifrar un mensaje de modo que solo la clave privada del destinatario pueda descifrar el mensaje. En la jerga de la seguridad, esto se conoce como "garantía de privacidad". Sin embargo, esto no proporciona prueba de que el remitente es quien dice ser, ya que cualquiera puede potencialmente usar una clave pública para enviarle a alguien un mensaje encriptado.

Hay casos en los que necesitamos verificar si el mensaje realmente vino de su remitente. En estos casos, utilizamos una firma y verificación de firma para asegurarnos de que el remitente es quien dice ser (también conocido como autenticidadEn una clave pública (también conocida como asimétrico) criptografía, esto generalmente se hace firmando el hash del mensaje para que solo la clave pública pueda verificarlo correctamente. El hash y la clave privada del remitente crean 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 acceder a las contraseñas?

Para acceder a las contraseñas, primero debemos generarlas y almacenarlas en algún lugar. Algunas de estas funciones se pueden proporcionar con un autenticador. autenticador es cualquier dispositivo compatible con hardware o software que proporciona la capacidad de generar una clave criptográfica. Considere esas contraseñas de un solo uso que obtiene de Autenticador de Google, 1 contraseñao Ultimo pasepor cierto.

Por ejemplo, un autenticador de software puede usar un módulo de plataforma segura (TPM) o un enclave de dispositivo seguro para crear credenciales. Luego, las credenciales se pueden almacenar de forma remota y sincronizar entre dispositivos, p. contraseñas Un autenticador de hardware sería algo así como YubiKeyque puede generar y almacenar claves en el propio dispositivo.

Para acceder al autenticador, el navegador necesita tener acceso al hardware y para eso necesitamos una interfaz. La interfaz que usamos 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 usando CTAP.

Una de las formas más interesantes de usar códigos de acceso es conectando su teléfono a través de Bluetooth a otro dispositivo que no admita códigos de acceso. 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 proxy!

La diferencia entre contraseñas y WebAuthn

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

En segundo lugar, para la autenticación del servidor, las claves WebAuthn deben proporcionar el identificador de usuario de inicio de sesión, luego allowCredentials El servidor devuelve la lista al cliente, que informa qué credenciales se pueden usar para iniciar sesión. Claves de acceso omita este paso y use el nombre de dominio del servidor para indicar qué claves ya están vinculadas a ese sitio. Puede elegir la contraseña que está asociada con este servidor ya que su sistema ya la conoce.

De lo contrario, las claves son criptográficamente idénticas; difieren solo 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 clave de acceso es muy similar: obtenga un desafío del servidor y luego use 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 que se almacenen.

Al recibir la clave pública y el desafío, el servidor valida el desafío y la sesión a partir de la cual se creó. Si esto se verifica, la clave pública se almacena, junto con cualquier otra información relevante, como la identificación del usuario o los datos de las credenciales, en una base de datos.

El usuario tiene un paso más: recuperar otro desafío del servidor y usar el navigator.credentials.get API de firma de desafíos. Enviamos el desafío firmado de regreso al servidor y el servidor verifica el desafío, luego nos registra si la firma pasa.

Por supuesto, hay un poco más en cada paso, pero básicamente, así es como iniciaríamos sesión en un sitio web usando WebAuthn o contraseñas.

Las claves y las patabras

Las claves de acceso se utilizan en dos fases separadas: atestación y declaración etapas.

La fase de autenticació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, pero en este caso usaremos nuestra clave de acceso.

La fase de verificación es similar a cómo iniciaría sesión en un sitio web después del registro.

Atestación

El navigator.credentials.create La API es el foco de nuestra fase de autenticació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. Esto significa que debe proporcionar opciones para navigator.credentials.create.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialCreationOptions = {
  challenge: safeEncode(challenge),
  rp: {
    id: window.location.host,
    name: document.title,
  },
  user: {
    id: new TextEncoder().encode(crypto.randomUUID()), // Why not make it random?
    name: 'Your username',
    displayName: 'Display name in browser',
  },
  pubKeyCredParams: [
    {
      type: 'public-key',
      alg: -7, // ES256
    },
    {
      type: 'public-key',
      alg: -256, // RS256
    },
  ],
  authenticatorSelection: {
    userVerification: 'preferred', // Do you want to use biometrics or a pin?
    residentKey: 'required', // Create a resident key e.g. passkey
  },
  attestation: 'indirect', // indirect, direct, or none
  timeout: 60_000,
};

const pubKeyCredential: PublicKeyCredential = await navigator.credentials.create({
  publicKey
});
const {
  id // the key id a.k.a. kid
} = pubKeyCredential;
const pubKey = pubKeyCredential.response.getPublicKey();
const { clientDataJSON, attestationObject } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for registration

Obtendremos PublicKeyCredential que contiene un AuthenticatorAttestationResponse Las credenciales tienen el identificador de par de claves generado.

La respuesta proporciona algunos bits de información útil. Primero, tenemos nuestra clave pública en esta respuesta y debemos enviarla al servidor para que la almacene. En segundo lugar, también volvemos clientDataJSON una propiedad que podemos decodificar y recuperar desde allí type, challengey origin de la clave de acceso.

Para atestación queremos confirmar type, challengey origin en el servidor, así como almacenar la clave pública con su identificador, p. attestationObject si lo desea Otra propiedad útil del almacenamiento es CÓMODAMENTE algoritmo que se define anteriormente en nuestro PublicKeyCredentialCreationOptions con alg: -7 o alg: -256para verificar fácilmente todos los desafíos firmados en la fase de afirmación.

Afirmación

El navigator.credentials.get La API será el foco de la fase de validación. Conceptualmente, aquí será donde el usuario ingrese a la aplicación web luego de registrarse.

// The `challenge` is random and has to come from the server
const publicKey: PublicKeyCredentialRequestOptions = {
  challenge: new TextEncoder().encode(challenge),
  rpId: window.location.host,
  timeout: 60_000,
};

const publicKeyCredential: PublicKeyCredential = await navigator.credentials.get({
  publicKey,
  mediation: 'optional',
});
const {
  id // the key id, aka kid
} = pubKeyCredential;
const { clientDataJSON, attestationObject, signature, userHandle } = pubKeyCredential.response;
const { type, challenge, origin } = JSON.parse(new TextDecoder().decode(clientDataJSON));
// Send data off to the server for verification

De nuevo obtendremos PublicKeyCredential con un AuthenticatorAssertionResponse esta vez, las credenciales incluyen nuevamente el identificador de clave.

también recibimos type, challengey origin de clientDataJSON de nuevo. signature ahora también está incluido en la respuesta authenticatorDataNecesitaremos estos y de clientDataJSON para verificar que este esté firmado con la clave privada.

El authenticatorData incluye algunas propiedades que vale la pena rastrear. Primero está el hash SHA256 de la fuente que está utilizando, que se encuentra dentro de los primeros 32 bytes, lo cual es útil para verificar que la solicitud provino del mismo servidor de origen. signCountque es el byte 33 a 37. Esto lo genera el autenticador y debe compararse con su valor anterior para asegurarse de que no le suceda nada sospechoso a la clave. El valor siempre debe ser 0 cuando se trata de una contraseña de varios dispositivos, y debe ser arbitrariamente mayor que el anterior signCount cuando se trata de una contraseña de un solo dispositivo.

Después de confirmar sus datos de inicio de sesión, debe iniciar sesión: Felicidades• Passkeys es un protocolo muy bueno, pero viene con algunas advertencias.

Algunos contras

Hay muchos aspectos positivos de las contraseñas, pero hay algunos problemas con ellas al momento de escribir esto. Por un lado, las contraseñas aún son un poco tempranas en términos de soporte, con solo credenciales de un solo dispositivo permitidas en Windows y muy poco soporte para sistemas Linux. Contraseñas.dev provee un una bonita mesa que es una especie de Caniuse de este protocolo.

Además, las plataformas de contraseñas de Google y Apple no se comunican entre sí. Si está buscando transferir sus credenciales desde su teléfono Android a su iPhone... bueno, no tiene suerte por ahora. ¡Esto no significa que no haya interoperabilidad! Puede iniciar sesión en su computadora usando su teléfono como autenticador. Pero sería mucho más limpio integrarlo en el sistema operativo y sincronizarlo sin que esté bloqueado a nivel del proveedor.

¿Adónde van las cosas?

¿Cómo es el protocolo de contraseñas del futuro? ¡Se ve bastante bien! Una vez que obtenga soporte de más sistemas operativos, debería haber aceptación y comenzará a usarlo más y más en la naturaleza. administradores de contraseñas incluso los apoyarán de primera mano.

Las claves de acceso de ninguna manera solo son compatibles con la red. Androide y iOS ambos mantendrán sus propias contraseñas como ciudadanos de primera clase. Todavía estamos en los primeros días de todo esto, pero espere verlo mencionado cada vez más.

¡Después de todo, estamos eliminando la necesidad de contraseñas y haciendo que el mundo sea más seguro para él!

Recursos

Aquí hay algunos recursos más si quieres para obtener más información sobre las contraseñas. También hay un repositorio y una demostración que preparé para este artículo.