1. Criptografía del lado del cliente
Los mensajes se cifran en el navegador usando Web Crypto (AES-GCM). El servidor almacena texto cifrado y metadatos.
Modelo de seguridad de EncSend
Esta página describe la implementación actual: qué datos se cifran del lado del cliente, cómo se gestionan los enlaces y las claves, qué controles de acceso están activos y dónde están los límites del modelo.
2. Claves en fragmentos de URL
Las claves de descifrado se transportan en fragmentos de URL como #k o #rk y no se envían al servidor.
3. Capa de contraseña opcional
Los enlaces protegidos con contraseña usan hashes de contraseña del lado del servidor más un encapsulado adicional de claves del lado del cliente (PBKDF2-SHA-256).
4. Controles de duración
La caducidad, los límites de visualización/envío y las políticas de lectura única restringen el acceso al contenido sensible.
Flujo de datos: envío de secreto
- 1. El navegador genera material de clave de enlace de 256 bits.
- 2. El mensaje se cifra con una clave de carga aleatoria mediante AES-GCM.
- 3. La clave de carga se encapsula con una clave HKDF-SHA-256 derivada de la clave del enlace.
- 4. Opcionalmente, esta clave encapsulada se cifra además con una capa basada en contraseña (PBKDF2-SHA-256).
- 5. El servidor almacena solo
encrypted_payload,encrypted_key, metadatos criptográficos y campos de política de acceso. - 6. Tras un descifrado local correcto, el cliente confirma una visualización; con lectura única, el secreto se marca después como destruido.
Flujo de datos: solicitud de mensaje seguro
- 1. El propietario genera una URL de solicitud con un token público aleatorio.
- 2. Los remitentes externos cifran localmente en el navegador con material de clave de solicitud procedente del fragmento de URL.
- 3. El servidor almacena los envíos como texto cifrado y aplica límites de envío y caducidad.
- 4. El propietario lee los envíos mediante descifrado local; el texto plano no se procesa en el servidor.
- 5. Para la lectura multidispositivo, la clave de solicitud puede almacenarse adicionalmente como un artefacto cifrado por el propietario.
Control de acceso y resistencia al abuso
Los tokens de acceso público se generan aleatoriamente, se almacenan solo como hashes SHA-256 en la base de datos y se validan mediante
hash_equals.
Las contraseñas de enlaces nunca se almacenan en texto plano y se comprueban contra hashes del lado del servidor. Las sesiones con contraseña para enlaces públicos tienen una duración limitada (120 minutos por defecto).
La limitación de tasa está activa para endpoints críticos, incluidas comprobaciones de contraseña, envíos públicos, inicio de sesión y flujos de verificación.
Las operaciones del lado del propietario están protegidas por autenticación, estado de correo verificado y políticas de autorización; los cambios sensibles de recuperación requieren una confirmación reciente de contraseña.
Recuperación del propietario y bóveda de claves
EncSend ofrece artefactos de recuperación cifrados opcionales para escenarios multidispositivo:
- Perfil criptográfico del propietario: clave maestra cifrada (AES-GCM), basada en frase de recuperación (PBKDF2-SHA-256).
- Bóveda de claves del usuario: copia de seguridad cifrada de las claves de secreto/solicitud almacenadas localmente.
- Claves de solicitud cifradas por el propietario por cada solicitud, incluidos lotes de rotación reanudables con soporte de reintento.
Auditoría y trazabilidad
Las acciones relevantes para la seguridad se registran (por ejemplo, emisión de enlaces, acceso denegado, pasos de comprobación de contraseña, creación de envíos y actualizaciones de recuperación).
- Las tablas de eventos de acceso almacenan el tipo de evento, la marca de tiempo, el agente de usuario y los metadatos contextuales.
- Registros de auditoría de eventos importantes.
- Una migración específica elimina las columnas de direcciones IP de las tablas relacionadas con sesiones y eventos.
Límites importantes del modelo
- La seguridad del navegador sigue siendo crítica: las claves locales se almacenan en caché en el navegador y requieren un entorno cliente reforzado.
- JavaScript y Web Crypto son obligatorios para los flujos seguros de creación y descifrado local.
- La seguridad del transporte (HTTPS, endurecimiento del proxy inverso y política TLS) debe aplicarse a nivel de infraestructura.
- El hash de contraseñas protege el almacenamiento del lado del servidor, pero no sustituye la elección de contraseñas seguras.