Planteamiento y contexto
Esta pregunta evalúa si un ingeniero de frontend puede integrar una extensión de WebAuthn en un flujo real de cifrado de extremo a extremo. PRF puede proporcionar una salida seudoaleatoria vinculada a credenciales para derivar material de clave del lado del cliente; no es una firma de inicio de sesión y no resuelve el uso multidispositivo, el respaldo, la eliminación o la compatibilidad del navegador. Una respuesta sólida cubre las API del navegador, los límites criptográficos, la experiencia del usuario y el riesgo de recuperación.
Qué está evaluando el entrevistador
- Si distingues la autenticación con passkeys del uso de material de clave con PRF.
- Si separas el soporte de extensiones, la verificación del usuario, las sales, la derivación y el almacenamiento en el servidor.
- Si manejas el registro de dispositivos, la eliminación de credenciales, la sincronización y la pérdida irrecuperable.
- Si defines el mecanismo de respaldo, los estados de error y el límite que mantiene el material de clave fuera del servidor.
Preguntas aclaratorias para hacer primero
Aclara el modelo de amenazas: ¿el servidor no es de confianza, la cadena de suministro del cliente está dentro del alcance y se requiere sincronización entre dispositivos? ¿Los datos se cifran como un todo o por campo, y pueden los usuarios aceptar una pérdida permanente después de perder las credenciales? ¿Están controlados los navegadores y WebViews de destino, y pueden los usuarios registrar múltiples passkeys? ¿Qué texto cifrado, sales, ID de credenciales y versiones debe almacenar el servidor?
Una estructura de respuesta de 30 segundos
Trataría a PRF como una fuente de material de clave del lado del cliente, sin usar una aserción de inicio de sesión como clave de cifrado. Durante el registro, crearía o seleccionaría una credencial compatible con PRF y generaría una sal impredecible por propósito. Durante el desbloqueo, realizaría una aserción con la entrada de PRF, derivaría una clave de envoltura con un KDF estándar en el navegador y desenvolvería una clave de datos. El servidor almacena claves públicas, sales, texto cifrado y versiones, nunca la salida de PRF. Comprobaría los resultados reales de la extensión y la verificación del usuario, prepararía una recuperación con múltiples credenciales o una advertencia de pérdida explícita, y me negaría a afirmar que hay cifrado de extremo a extremo cuando PRF no esté disponible. Ampliaría el soporte solo después de medir las fallas, la recuperación y la compatibilidad.
Análisis detallado paso a paso
1. Separar la autenticación de las claves de cifrado
El inicio de sesión con WebAuthn devuelve una firma sobre un desafío para demostrar la posesión de una credencial. La extensión PRF produce una salida seudoaleatoria asociada a la credencial a partir de una entrada. Una firma, un ID de credencial o un JSON de extensión del cliente no deben usarse directamente como una clave AES. El diseño necesita una clave de datos independiente y una relación explícita de derivación y envoltura.
2. Diseñar el registro y las sales
Solicita la extensión PRF durante el registro y exige la verificación del usuario. Genera una sal aleatoria por dominio de cifrado o versión de clave, luego almacena la sal, el ID de la credencial y la versión del algoritmo como metadatos públicos. Una sal no es secreta, pero los propósitos deben estar separados; cambiar de propósito o rotar una clave requiere una nueva sal. Comprueba la salida de la extensión del cliente devuelta en lugar de inferir el soporte a partir de la solicitud.
3. Diseñar el desbloqueo y la derivación
Obtén las sales y los metadatos del texto cifrado del servidor, luego realiza una aserción con la entrada de PRF. Valida la estructura y la longitud de la extensión devuelta en el navegador, deriva una clave de envoltura con un KDF estándar, desenvuelve una clave de datos generada aleatoriamente y descifra el contenido. Mantén la salida de PRF y las claves intermedias en memoria solo según sea necesario; nunca las incluyas en registros ni en telemetría.
4. Manejar la detección de capacidades y la compatibilidad
Usa comprobaciones de capacidad documentadas y getClientExtensionResults() para inspeccionar el resultado real. Distingue entre extensiones no admitidas, cancelación del usuario, una credencial no inicializada y fallas de red. El estado de implementación de W3C todavía necesita verificación en los navegadores, sistemas operativos y WebViews de destino; el éxito en un navegador no es una garantía para toda la plataforma. Registra la matriz de compatibilidad y las versiones mínimas en la política de despliegue.
5. Diseñar múltiples dispositivos y recuperación
Registra una credencial independiente por dispositivo y mantén una copia envuelta por separado de la misma clave de datos para cada uno. Un nuevo dispositivo necesita un dispositivo ya desbloqueado, una clave de recuperación o una invitación controlada para reenvolver la clave de datos; un inicio de sesión en el servidor por sí solo no debe descifrarla. Si se eliminan todas las credenciales y no existe material de recuperación, indica claramente que los datos son irrecuperables y obtén la confirmación antes de habilitar la función.
6. Planificar el mecanismo de respaldo y la migración
Cuando PRF no esté disponible, mantén un modo de cifrado legible por el servidor, guía al usuario a un navegador compatible o bloquea el modo de extremo a extremo, según el modelo de amenazas. Etiqueta el mecanismo de respaldo de forma explícita; no mezcles niveles de seguridad en una sola interfaz de usuario. Versiona algoritmos, sales y formatos de texto cifrado para que la migración futura y la revocación de credenciales antiguas sigan siendo posibles.
Respuesta modelo de alta calidad
Usaría WebAuthn PRF como material de clave del lado del cliente, nunca trataría una firma de inicio de sesión o un ID de credencial como una clave de cifrado. En el registro, solicitaría PRF, requeriría verificación de usuario, generaría una sal aleatoria por dominio de cifrado y almacenaría el ID de la credencial, la sal y la versión del algoritmo. Al desbloquear, obtendría los metadatos, realizaría una aserción con la entrada de PRF, derivaría una clave de envoltura con un KDF estándar en el navegador, desenvolvería una clave de datos generada aleatoriamente y descifraría. El servidor almacena claves públicas, texto cifrado y metadatos públicos; la salida de PRF, las claves intermedias y el texto en plano permanecen en el lado del cliente. Inspeccionaría getClientExtensionResults() para distinguir estados no admitidos, no inicializados, cancelados y errores de red. Cada dispositivo obtiene su propia credencial y copia envuelta de la clave de datos; agregar un dispositivo requiere un dispositivo desbloqueado o material de recuperación, y perder todas las credenciales es explícitamente irrecuperable. Si PRF no está disponible, mostraría un mecanismo de respaldo explícito o bloquearía la activación, para luego expandir según la matriz de navegadores, la tasa de fallas y el éxito de la recuperación.
Errores comunes
- Usar una firma de WebAuthn, un ID de credencial o el JSON de extensión del cliente directamente como una clave simétrica.
- Comprobar solo que la solicitud contiene un parámetro PRF en lugar de verificar la salida real y la inicialización.
- Tratar las sales como secretos o reutilizar una misma sal para distintos propósitos.
- Enviar la salida de PRF al servidor o registrar material de clave en logs, trazas o análisis.
- Diseñar solo el camino feliz de un único dispositivo sin considerar el registro, la eliminación y la recuperación.
- Cambiar silenciosamente a un modo más débil sin dejar de etiquetarlo como cifrado de extremo a extremo.
Preguntas de seguimiento y respuestas
¿Se puede usar la salida de PRF directamente como una clave AES-GCM?
Usa primero un KDF estándar y separación de dominios, luego deriva una clave de envoltura de longitud fija. No expongas la salida del protocolo a múltiples propósitos de cifrado. Genera una clave de datos aleatoria y envuélvela; no hagas que cada clave de texto cifrado sea una función directa de la credencial.
¿Puede el servidor desbloquear a un usuario en otro dispositivo después de iniciar sesión?
El servidor puede proporcionar sales, texto cifrado y metadatos de credenciales, pero no puede reconstruir la salida de PRF a partir de un inicio de sesión. Un dispositivo desbloqueado, una clave de recuperación o un flujo de uso compartido de claves explícitamente diseñado debe envolver la clave de datos para el nuevo dispositivo.
¿Cómo sabes si un navegador realmente admite PRF?
Declara la extensión, lee la salida de la extensión del cliente de la aserción y comprueba los campos esperados, la longitud y los estados de error. Mantén una matriz empírica para los navegadores, sistemas operativos y WebViews de destino. Una API de capacidades indica que se puede solicitar una extensión; no reemplaza una ceremonia real.
¿El cifrado de extremo a extremo sigue siendo seguro si se inyecta un script entregado por el servidor?
PRF no resuelve una manipulación activa del script del frontend. También necesitas una política de seguridad de contenido, integridad de dependencias y de versiones, aislamiento de operaciones sensibles y auditoría. Establece claramente que "el servidor no puede leer el texto cifrado histórico" y "el entorno de ejecución del cliente es de confianza" son suposiciones diferentes.