Criptografia del lado del cliente primero
Los mensajes se cifran en el navegador con Web Crypto (AES-GCM). El servidor solo almacena texto cifrado y metadatos.
Modelo de seguridad de EncSend
Esta pagina describe la implementacion actual: que datos se cifran del lado del cliente, como se gestionan los enlaces y las claves, que controles de acceso estan activos y donde estan los limites del modelo.
Claves en fragmentos de URL
Las claves de descifrado se transportan en fragmentos de URL como #k o #rk y no se envian al servidor.
Capa opcional de contrasena
Los enlaces protegidos por contrasena utilizan hashes del lado del servidor mas un wrapping adicional de claves del lado del cliente con PBKDF2-SHA-256.
Controles de vida util
Las expiraciones, limites de apertura o envio y las politicas de lectura unica restringen el acceso al contenido sensible.
Flujo de datos: envio de secreto
- El navegador genera material de clave de enlace de 256 bits.
- El mensaje se cifra con una clave de carga aleatoria mediante AES-GCM.
- La clave de carga se envuelve con una clave derivada de la clave del enlace mediante HKDF-SHA-256.
- Opcionalmente, esta clave envuelta se cifra ademas con una capa basada en contrasena (PBKDF2-SHA-256).
- El servidor solo almacena
encrypted_payload,encrypted_key, metadatos criptograficos y campos de politica de acceso. - Despues del descifrado local correcto, el cliente confirma la visualizacion; con lectura unica, el secreto se marca despues como destruido.
Flujo de datos: solicitud de mensaje seguro
- El propietario genera una URL de solicitud con un token publico aleatorio.
- Los remitentes externos cifran localmente en el navegador con material de clave obtenido del fragmento de la URL.
- El servidor almacena los envios como texto cifrado y aplica limites de envio y expiracion.
- El propietario lee los envios mediante descifrado local; el texto en claro no se procesa en el servidor.
- Para lectura entre dispositivos, la clave de solicitud puede almacenarse tambien como artefacto owner-wrapped.
Control de acceso y resistencia al abuso
Los tokens de acceso publicos se generan aleatoriamente, se almacenan solo como hashes SHA-256 en la base de datos y se validan mediante hash_equals.
Las contrasenas de enlace nunca se almacenan en texto plano y se comprueban contra hashes del lado del servidor. Las sesiones de contrasena para enlaces publicos tienen limite de tiempo y son configurables.
El rate limiting esta activo en puntos criticos, incluidas comprobaciones de contrasena, envios publicos, inicio de sesion y flujos de verificacion.
Las operaciones del propietario estan protegidas por autenticacion, estado de correo verificado y politicas de autorizacion; las mutaciones sensibles de recuperacion requieren una confirmacion reciente de contrasena.
Recuperacion del propietario y vault de claves
EncSend ofrece artefactos de recuperacion cifrados opcionales para escenarios entre dispositivos:
- Perfil criptografico del propietario: clave maestra cifrada (AES-GCM), basada en frase secreta con PBKDF2-SHA-256.
- Vault de claves del usuario: copia de seguridad cifrada de las claves de secretos y solicitudes almacenadas localmente.
- Claves de solicitud owner-wrapped por solicitud y claves de secreto owner-wrapped por secreto; los lotes de rotacion de claves de solicitud incluyen soporte de reintento.
Auditoria y trazabilidad
Las acciones relevantes para la seguridad se registran, por ejemplo emision de enlaces, accesos denegados, pasos de desafio por contrasena, creacion de envios y actualizaciones de recuperacion.
- Las tablas de eventos de acceso conservan el tipo de evento, la marca de tiempo, el user-agent y metadatos contextuales.
- Los registros de auditoria son consultables por los usuarios finales (sus propios eventos) y por administradores (vista global).
- Una migracion dedicada elimina columnas de direccion IP de las tablas de sesiones y eventos.
Limites importantes del modelo
- La seguridad del navegador sigue siendo critica: las claves locales se almacenan en cache en el navegador y requieren un entorno cliente endurecido.
- JavaScript y Web Crypto son obligatorios para los flujos seguros de creacion y descifrado local.
- La seguridad del transporte (HTTPS, endurecimiento del reverse proxy y politica TLS) debe imponerse a nivel de infraestructura.
- El hash de contrasenas protege el almacenamiento del lado del servidor, pero no sustituye contrasenas fuertes.