Planteamiento y contexto
La aplicación cifra datos locales en el navegador y necesita una clave a través de las sesiones. El diseño debe reducir la exposición de la clave, pero debe indicar sus límites: el código que se ejecuta en el origen aún puede invocar operaciones permitidas y los usuarios pueden perder la capacidad de recuperación.
Qué evalúa el entrevistador
- Comprensión de contextos seguros, extractabilidad de CryptoKey y usos de claves.
- Separación del almacenamiento de datos cifrados de la recuperación de claves y el modelado de amenazas.
- Explicación de por qué la criptografía en el navegador no hace que XSS sea inofensivo.
Preguntas para clarificar antes de responder
- ¿La amenaza es un registro de almacenamiento robado, un atacante pasivo o un script activo del mismo origen?
- ¿Los datos deben sobrevivir al cierre de sesión, la pérdida del dispositivo, el restablecimiento de contraseña y la eliminación del perfil del navegador?
- ¿Puede una frase de contraseña proporcionada por el usuario o una credencial de WebAuthn desbloquear una clave de envoltura (wrapping key)?
- ¿Qué algoritmos, usos de clave, soporte de navegadores y rutas de migración se requieren?
Estructura de respuesta en 30 segundos
Requeriría HTTPS, generaría o importaría un CryptoKey con extractable establecido en false y solo los usos necesarios, y almacenaría el identificador de la clave en IndexedDB en lugar de exportar los bytes sin procesar de la clave. El texto cifrado, el nonce, los parámetros del algoritmo y la versión se mantienen separados de la clave. Combinaría esto con CSP, controles estrictos de dependencias y un plan de recuperación, dejando en claro que un script activo del mismo origen aún puede llamar a las API de cifrado o leer texto plano cuando la aplicación está abierta.
Análisis detallado paso a paso
1. Definir el modelo de amenazas
La no extractabilidad limita la exportación accidental y muchas rutas de robo de almacenamiento. No detiene a un atacante que ejecuta scripts en el origen para solicitar a la aplicación que descifre datos o lea texto plano en memoria. Establezca ese límite antes de prometer seguridad.
2. Crear o importar la clave
Utilice un algoritmo compatible y usos específicos para su propósito, como encrypt y decrypt. Genere la clave en un contexto seguro o importe material envuelto con el indicador de extractabilidad deseado. Rechace parámetros de algoritmo inesperados y evite almacenar material de claves sin procesar en el almacenamiento local.
3. Persistir el texto cifrado de forma segura
Almacene el texto cifrado, un nonce nuevo por cifrado, metadatos autenticados, versión de la clave y versión del esquema. Utilice cifrado autenticado como AES-GCM con nonces únicos bajo una misma clave. Mantenga el alcance del inquilino o usuario en los datos asociados, no como una decisión de confianza implícita.
4. Planificar la recuperación y rotación
Una clave no extraíble puede quedar inutilizable tras la eliminación del perfil o la pérdida del dispositivo. Ofrezca una ruta de recuperación deliberada, por ejemplo, una clave de envoltura derivada de una frase de contraseña o un flujo de re-cifrado mediado por el servidor, sin degradar silenciosamente a texto plano. Controle las versiones de las claves y migre los registros de forma transaccional.
5. Probar y operar
Pruebe algoritmos no compatibles, contextos inseguros, errores de cuota, escrituras interrumpidas, reutilización de nonce, migración de versiones, cierre de sesión y fallas de recuperación. Aplique CSP y revisión de dependencias, evite registros confidenciales y mida los fallos de descifrado sin registrar texto plano.
Ejemplo de respuesta de alta calidad
“Requeriría HTTPS, generaría un CryptoKey de propósito limitado con extractable en false y persistiría solo su identificador administrado por el navegador en IndexedDB. Cada registro almacena texto cifrado, un nonce único, metadatos autenticados y la versión de la clave. Definiría la recuperación antes del lanzamiento porque la pérdida del perfil puede hacer que una clave no extraíble sea irrecuperable. CSP y los controles de dependencias reducen el riesgo de scripts activos, pero una carga útil de XSS que se ejecute en el origen aún puede invocar operaciones de descifrado permitidas o leer texto plano mientras la aplicación esté abierta.”
Errores comunes
- Almacenar la clave sin procesar en localStorage → el robo de almacenamiento expone el acceso en texto plano → persistir un identificador de clave no extraíble.
- Reutilizar un nonce con AES-GCM → la confidencialidad y la integridad pueden fallar → generar un nonce único por clave y registro.
- Afirmar que XSS está resuelto → el código del mismo origen puede usar la autoridad de la aplicación → indicar el límite frente a scripts activos.
- Omitir el diseño de recuperación → la pérdida de perfil destruye el acceso a los datos → definir flujos de envoltura, restablecimiento y migración.
Preguntas de seguimiento y respuestas
¿IndexedDB hace que la clave sea segura contra XSS?
No. Evita colocar bytes sin procesar en una API de almacenamiento simple, pero los scripts del mismo origen pueden acceder a la base de datos o llamar al código de la aplicación. Utilice CSP, dependencias confiables y un modelo de amenazas realista.
¿Cómo puede un usuario recuperarse tras la pérdida del dispositivo?
Envuelva una clave de datos con una clave derivada de un secreto en posesión del usuario o una credencial de recuperación, o vuelva a cifrar mediante un flujo autenticado en el servidor. Explique los compromisos fuera de línea y de restablecimiento; nunca cree silenciosamente una nueva clave que no pueda descifrar datos antiguos.
¿Se puede exportar la clave durante la rotación?
Solo si la política lo permite. Es preferible generar una nueva clave y volver a cifrar los registros mientras ambas versiones estén disponibles; si se requiere envoltura, proteja la clave de envoltura y audite la transición.