Seguridad en LangReply
Lo que ciframos, lo que destruimos y lo que honestamente no podemos garantizar. Escrito sin jerga de marketing.
1. Cifrado en reposo
Los datos sensibles (cuentas de usuario, historiales de traducción, mensajes OTT, preferencias) se cifran en reposo con AES-256-GCM. La clave maestra reside fuera del repositorio Git, en un volumen de acceso restringido (permisos 600, propietario dedicado).
Cada registro sensible lleva su propio IV (nonce aleatorio de 96 bits) y su etiqueta de autenticación GCM. Cualquier alteración del texto cifrado se detecta al descifrar (fallo criptográfico, sin corrupción silenciosa).
Excepción documentada: el archivo languages.json (la lista pública de idiomas admitidos) queda explícitamente excluido del cifrado: es un catálogo público, no un dato personal.
2. Borrado irreversible (crypto-shredding)
Principio
Cada conversación OTT, cada lote de mensajes sensibles y cada cuenta de usuario tienen su propia DEK (Data Encryption Key): una clave AES-256 única, generada aleatoriamente. Los datos se cifran con esa DEK; la DEK, a su vez, se cifra con la clave maestra (KEK).
Para borrar los datos de forma irreversible, destruimos la DEK. Los bytes cifrados pueden seguir presentes en la base de datos o en disco: sin la clave, son indistinguibles del ruido aleatorio.
Garantía matemática
Una DEK AES-256 tiene un espacio de 2256 valores posibles, unos 1,16 × 1077. Recuperar por fuerza bruta una clave destruida es, dado el estado actual del conocimiento público en criptografía y de la potencia de cálculo disponible (incluida la proyección poscuántica con Grover, que lo reduce a 2128), inviable.
Qué se destruye realmente
- La DEK en RAM (puesta a cero inmediata).
- La DEK cifrada en la base de datos (
UPDATE ... SET encrypted_dek = NULL+VACUUMde Postgres cuando procede). - Las copias en la caché de la aplicación.
3. Mensajes que desaparecen automáticamente
Cualquier conversación OTT puede activar un temporizador de autopurga: pasado ese plazo, los mensajes se destruyen mediante crypto-shredding de la DEK de la conversación.
Duraciones configurables
- 1 hora
- 24 horas
- 7 días
- 30 días
- Desactivado
Si no se configura nada, no se aplica ninguna duración por defecto: los mensajes se conservan hasta su eliminación manual.
El plazo empieza a contar cuando el mensaje es leído por el destinatario (opción por defecto) o cuando se envía (opción alternativa). Un barredor del servidor se ejecuta cada 10 minutos y purga lo que ha expirado.
El cambio de plazo es visible en la conversación (mensaje de sistema con marca de tiempo). Ni el remitente ni el destinatario pueden «prolongar» un mensaje ya expirado: la clave está destruida.
4. Purga extrema de la cuenta
En el portal de usuario, el botón «Destruir todos mis mensajes» desencadena la destrucción inmediata de todas las DEK asociadas a su cuenta: conversaciones OTT, historial de traducción, borradores y adjuntos cifrados.
La operación es:
- Instantánea a nivel criptográfico (la clave desaparece en milisegundos).
- Irreversible: no conservamos ninguna copia de seguridad de las DEK destruidas.
- Confirmada mediante doble consentimiento (su contraseña + una frase de confirmación).
- Registrada (metadatos de auditoría: marca de tiempo, IP, user-agent) sin exponer el contenido destruido.
Una purga de la cuenta no elimina la cuenta en sí (identificador, correo, preferencias de facturación): para eso, utilice la eliminación completa de la cuenta, que es una acción distinta.
5. Aislamiento por cuenta
Cada cuenta tiene su propia DEK. El compromiso de una DEK expone únicamente los datos de esa cuenta, no los de las demás. La clave maestra (KEK) es necesaria para descifrar las DEK, pero por sí sola no permite leer una cuenta cuya DEK ya no está en la base de datos.
Las peticiones de la API están acotadas por account_id. Ninguna ruta acepta el identificador de una cuenta como parámetro libre sin verificar la pertenencia de la sesión.
6. Motor de traducción autoalojado
La traducción principal utiliza NLLB-200 1.3B (202 idiomas) alojado en nuestro propio servidor, en un microservicio interno no expuesto a Internet. El contenido no sale de nuestra infraestructura para ser traducido.
Respaldo: en caso de indisponibilidad, un mecanismo automático puede recurrir únicamente a Claude (Anthropic). Este respaldo se puede desactivar por cuenta para usos sensibles; cuando se activa, el contenido se transmite a Anthropic y lo señalamos en la respuesta de la API.
El respaldo MyMemory se retiró el 28 de julio de 2026: transmitía el contenido en claro dentro de la URL, sin contrato de encargo del tratamiento. No existe un tercer recurso: si ningún motor está disponible, la traducción falla en lugar de confiarse a un tercero sin contrato.
7. Autenticación
Contraseñas hasheadas con scrypt (N=16384, r=8, p=1). Sesiones mediante cookie HttpOnly firmada con HMAC. 2FA disponible: TOTP (Google Authenticator, Aegis, 1Password) y OTP por SMS (Twilio, con mensajes localizados en el idioma del destinatario).
Limitación de tasa en los endpoints de autenticación (429 tras intentos repetidos). Ninguna contraseña se envía por correo; los restablecimientos usan un enlace de un solo uso.
8. Copias de seguridad
Copias cifradas diarias del volumen de datos. Retención: 14 días móviles y después se eliminan.
Se conserva una copia cifrada fuera del sitio (AES-256) en GitHub y Backblaze (Estados Unidos). Los mensajes OTT/SMS y sus claves quedan excluidos y nunca salen de la Unión Europea.
9. Sus derechos (RGPD / Ley 25 / CCPA)
Derecho de acceso, rectificación, supresión, portabilidad y oposición. Las solicitudes se envían por correo a privacy@langreply.com y se atienden en un plazo de 30 días. La supresión utiliza la purga por crypto-shredding descrita más arriba.
10. Certificaciones — con honestidad
Hoy no estamos certificados en SOC 2, ISO 27001 ni HIPAA. No lo afirmaremos hasta que sea cierto. Las medidas descritas aquí están realmente implantadas; las auditorías externas correspondientes todavía no.
11. Lo que honestamente no garantizamos
Preferimos decir la verdad antes que vender una ilusión. Esto es lo que el crypto-shredding no hace:
- Copias de seguridad: nuestras copias excluyen las tablas de mensajes y de claves, por lo que una restauración no puede volver a exponer un mensaje destruido. Contrapartida asumida: si se pierde la base de datos, el historial OTT/SMS no es recuperable.
- Capturas de pantalla del destinatario: si envía un mensaje que desaparece, esa persona puede fotografiar su pantalla con otro dispositivo. Ningún software del mundo puede impedirlo. Signal tampoco.
- WAL, registros, réplicas: Postgres escribe registros de transacciones (WAL). Un byte cifrado puede haber pasado por ellos antes de borrarse. Esos registros rotan, pero no de forma instantánea.
- SSD y nivelación de desgaste: los discos SSD reparten físicamente las escrituras. Un
DELETElógico no sobrescribe necesariamente el sector físico. Precisamente por eso el crypto-shredding es más fiable que un borrado físico, pero el byte cifrado puede subsistir físicamente algún tiempo. Sin la clave, sigue siendo ilegible. - Metadatos de auditoría: conservamos metadatos mínimos (marca de tiempo de una purga, IP) para auditoría y lucha contra el abuso. No contienen el contenido destruido.
- Cifrado de extremo a extremo: la mensajería OTT se cifra en reposo del lado del servidor, pero no es E2EE en el sentido de Signal (donde ni siquiera el servidor puede leer). Técnicamente, LangReply puede descifrar un mensaje mientras exista su DEK. No lo hacemos, pero no podemos pretender lo contrario.
12. Notificar un problema de seguridad
Divulgación coordinada en security@langreply.com con el asunto [SECURITY]. Acusamos recibo en 72 h y publicamos una corrección o mitigación en un plazo razonable según la gravedad. Todavía no hay un programa formal de bug bounty; mencionamos a quienes lo deseen.
Última actualización: 6 de agosto de 2026.