TL;DR
Worklist usa cifrado ChaCha20-Poly1305 con arquitectura de conocimiento cero. Tus datos se cifran en tu dispositivo con primitivas criptográficas documentadas antes de llegar a nuestros servidores. Aunque tuviéramos acceso total a la base de datos, físicamente no podemos leer tus tareas. Una clave de respaldo que guardes puede restaurar el acceso una sola vez si pierdes la contraseña, sin entregar a Worklist una clave de descifrado. La arquitectura respalda la minimización de datos del RGPD y puede ayudar con salvaguardas técnicas de HIPAA/SOC 2 cuando se acompaña de los acuerdos y controles operativos necesarios.
Nuestro principio fundamental.
Tus datos se cifran en tu dispositivo antes de llegar a nuestros servidores. Diseñamos Worklist para que nosotros — la empresa — no podamos descifrar, leer ni acceder a tus listas de trabajo, tareas o comentarios. A esto se le llama arquitectura de conocimiento cero.
Lo que hace a Worklist diferente.
Gestores de tareas tradicionales.
Lo que hace la competencia
- • Almacenan tus datos en texto plano en sus servidores
- • Pueden leer cada tarea, comentario y archivo que creas
- • Pueden analizar tu contenido para publicidad, entrenamiento de IA o «funcionalidades»
- • Vulnerables a brechas de datos que lo exponen todo
Worklist (conocimiento cero).
Lo que hacemos nosotros
- • Cifra en tu dispositivo antes de enviar a nuestros servidores
- • No podemos descifrar tus tareas, aunque quisiéramos
- • Sin escaneo ni entrenamiento de IA con tu trabajo privado
- • Las brechas no revelan nada útil: solo bloques cifrados
Cómo funciona el cifrado de conocimiento cero.
Creas tu cuenta.
Al registrarte, tu contraseña nunca sale del navegador en texto plano. En su lugar:
- Usamos el protocolo OPAQUE PAKE para que nuestros servidores nunca vean tu contraseña en texto plano
- Después de registrarte o iniciar sesión correctamente, OPAQUE entrega al navegador una clave de exportación secreta que nunca recibimos
- Se genera en tu dispositivo una «clave de datos» aleatoria de 32 bytes
- Esa clave de datos se cifra localmente con una clave de envoltura derivada de esa clave de exportación OPAQUE
- La clave de datos cifrada se guarda en nuestros servidores, pero no podemos descifrarla sin el material de desbloqueo del cliente
- Puedes descargar una clave de respaldo de un solo uso. Envuelve la misma clave de datos en tu navegador, y nosotros solo guardamos una envoltura de recuperación cifrada
Punto clave: la clave de desbloqueo y la clave de datos se manejan en tu navegador. Solo almacenamos envolturas cifradas, nunca contraseñas en texto plano ni claves del workspace.
¿Por qué guardar la clave de datos cifrada?
Para que puedas iniciar sesión desde cualquier dispositivo. Cuando cambias de ordenador o usas el móvil, enviamos el blob cifrado, tu navegador lo desbloquea localmente tras el inicio de sesión seguro y listo. Sin guardarlo, tendrías que copiar manualmente una clave de 32 bytes entre dispositivos — UX terrible para la misma seguridad.
Creas una lista de trabajo o una tarea.
Cada dato sensible se cifra en tu dispositivo:
- Títulos, descripciones y ajustes de las listas de trabajo
- Títulos, contenidos, checklists y comentarios de las tareas
- Plantillas de tareas recurrentes y programaciones
- Todo se cifra con ChaCha20-Poly1305 AEAD (un cifrado moderno y auditado)
- Cada lista de trabajo tiene su propia clave de cifrado derivada de tu clave de datos
Nuestros servidores almacenan solo el texto cifrado: no pueden leer el texto plano.
Invitas a tus compañeros.
Al compartir listas de trabajo con tu equipo:
- Cada miembro recibe su propia copia cifrada de la clave de la lista
- Las claves se intercambian con HPKE (cifrado híbrido de clave pública)
- Las claves públicas se publican en un registro de transparencia (árbol de Merkle) para evitar ataques de intermediario
- Si retiras a un miembro, la clave de la lista se rota y todos los demás reciben nuevas copias cifradas
Nuestros servidores verifican sin descifrar.
Quizá te preguntes: «Si el servidor no puede descifrar, ¿cómo aplica los permisos?»
Usamos pruebas HMAC: firmas criptográficas que demuestran que tienes derecho a acceder a los datos sin revelar el texto plano.
- Tu navegador calcula un HMAC (hash con clave) sobre los datos cifrados usando una clave específica de membresía
- El servidor valida el HMAC para confirmar que eres miembro activo
- Manipular o reproducir datos ajenos no supera la comprobación HMAC
- Nunca desciframos el contenido: solo verificamos integridad y autorización
Lo que nuestros servidores pueden (y no pueden) ver.
NO podemos ver
- × Títulos o descripciones de las listas de trabajo
- × Títulos, contenidos o checklists de las tareas
- × Comentarios o discusiones
- × Plantillas de tareas recurrentes
- × Cualquier contenido dentro de paquetes cifrados
- × Tu contraseña (ni siquiera el hash)
SÍ podemos ver
- ✓ Correo de la cuenta (para iniciar sesión)
- ✓ Relaciones de membresía (quién está en cada lista)
- ✓ Estado de la tarea (abierta/cerrada) y prioridad
- ✓ Fechas de vencimiento y marcas temporales
- ✓ Asignaciones de delegación (solo IDs de usuario)
- ✓ Metadatos necesarios para las consultas (IDs, fechas de creación)
Por qué algunos metadatos son visibles: Algunos campos (como el estado de la tarea y las fechas de vencimiento) deben guardarse en texto plano para que los servidores filtren las consultas eficientemente, lancen recordatorios y mantengan los índices de la base de datos. Estos campos no contienen información sensible: solo los metadatos operativos necesarios para que la app funcione.
Garantías de seguridad.
Desbloqueo autenticado por contraseña (solo en el cliente).
Tu contraseña nunca sale del dispositivo en texto plano. Una autenticación OPAQUE correcta entrega al navegador una clave de exportación que desenvuelve localmente tu clave de datos. Esa clave de datos se expande luego con HKDF para derivar claves separadas para cada lista de trabajo.
El servidor no puede descifrar contenidos.
Nuestro código backend nunca ejecuta operaciones de descifrado sobre datos de usuario. Solo valida pruebas HMAC para confirmar la autorización.
Rotación de claves al cambiar miembros.
Cuando se retira o sale un miembro, se rota la clave de la lista de trabajo. Todos los miembros restantes reciben nuevas copias cifradas, garantizando que el miembro saliente no pueda descifrar los futuros contenidos.
Transparencia de claves de invitación.
Las claves públicas para las invitaciones se registran en un árbol de Merkle solo de adición. Los clientes verifican pruebas de inclusión y consistencia, impidiendo que el servidor sustituya claves silenciosamente para interceptar los datos.
Las claves de respaldo siguen siendo de conocimiento cero.
La clave de respaldo se genera en tu navegador y debes guardarla tú. Crea una envoltura cifrada separada para la misma clave de datos; nosotros solo almacenamos el archivo de credenciales de recuperación y la envoltura cifrada, así que no podemos restablecer tu contraseña ni leer tus datos sin esa clave guardada.
Criptografía de código abierto.
Usamos bibliotecas probadas: strong-box (ChaCha20-Poly1305), OPAQUE (autenticación por contraseña), HKDF (derivación de claves), Argon2id (endurecimiento de contraseñas de OPAQUE y migración heredada) y HPKE (intercambio de claves). Todo nuestro código criptográfico es de código abierto y auditable.
Cómo verificamos nuestra seguridad.
Nuestras afirmaciones de seguridad son verificables, no solo marketing. Así garantizamos que nuestra arquitectura de conocimiento cero funciona como prometemos:
- Código criptográfico de código abierto en GitHub para que cualquier investigador de seguridad pueda auditarlo
- Bibliotecas probadas como ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9497) y HPKE
- Pruebas criptográficas (HMAC) que matemáticamente impiden el descifrado en el servidor
- Registros de transparencia (árboles de Merkle) para detectar ataques de sustitución de claves
- El desbloqueo en el cliente desde claves de exportación OPAQUE garantiza que nunca veamos tu contraseña ni tus claves de cifrado
- Las claves de respaldo de un solo uso las genera y conserva el usuario, nunca Worklist
Compromisos del conocimiento cero.
Una clave de respaldo puede restaurar el acceso si pierdes la contraseña.
Guarda una clave de respaldo una vez y mantenla privada. Si pierdes la contraseña, esa clave te permite restablecerla y conservar el acceso a los datos cifrados. Como Worklist no guarda una copia, las cuentas sin una clave de respaldo guardada no se pueden recuperar.
No hay búsqueda en el servidor.
Como el contenido de tus tareas está cifrado, no podemos ofrecer búsqueda completa en el servidor sobre todas tus tareas. La búsqueda ocurre en tu navegador tras el descifrado.
Mitigación: optimizamos la búsqueda en el cliente con búsquedas indexadas y descifrado rápido para mantenerla ágil.
Especificaciones técnicas.
| Cifrado simétrico | ChaCha20-Poly1305 AEAD (mediante la biblioteca strong-box) |
| Desbloqueo de clave de datos | Clave de exportación OPAQUE + HKDF-SHA256 — deriva claves de envoltura locales para la clave de datos cifrada |
| Jerarquía de claves | HKDF-SHA256 — deriva claves de listas y membresías a partir de la clave de datos |
| Autenticación por contraseña | OPAQUE PAKE (curva Ristretto255) |
| Claves de respaldo | Una clave de respaldo activa de un solo uso por usuario; generada en el cliente y guardada por el usuario |
| Intercambio de claves (invitaciones) | HPKE (cifrado híbrido de clave pública) con X25519 |
| Pruebas de integridad | HMAC-SHA256 |
| Serialización | CBOR (Concise Binary Object Representation) |
| Tamaño de clave | 256 bits (32 bytes) para todas las claves simétricas |
Todas las operaciones criptográficas suceden en tu navegador con las API WebCrypto y módulos WASM auditados compilados desde Rust.
Auditorías y transparencia.
Stack criptográfico de código abierto.
Toda nuestra implementación criptográfica es de código abierto y está disponible en GitHub. Invitamos a los investigadores de seguridad a auditar nuestro código.
Ver en GitHubCumplimiento.
Nuestra arquitectura de conocimiento cero respalda la minimización de datos del RGPD y puede ayudar con salvaguardas técnicas de HIPAA o SOC 2. La PHI regulada sigue requiriendo un acuerdo escrito o BAA, además de los controles operativos y la confirmación del proveedor que exija tu programa de cumplimiento.
Preguntas frecuentes.
¿Qué pasa si os hackean?
Si un atacante accede a nuestra base de datos, solo verá bloques cifrados — básicamente bytes aleatorios. Sin el desbloqueo autenticado por tu contraseña o una clave de respaldo guardada, descifrar los datos es matemáticamente imposible con la tecnología actual.
¿Pueden las autoridades obligaros a descifrar mis datos?
No, porque genuinamente no podemos. No tenemos las claves. Incluso con una orden judicial solo podemos entregar los textos cifrados — inútiles sin el desbloqueo autenticado por tu contraseña o una clave de respaldo que hayas guardado.
¿Qué pasa si olvido mi contraseña?
Si guardaste una clave de respaldo, puedes usarla una sola vez para restablecer la contraseña y mantener el acceso a tus datos cifrados. Si no guardaste una clave de respaldo, Worklist no puede restaurar los datos por ti.
¿En qué se diferencia del «cifrado en reposo»?
El «cifrado en reposo» significa que los datos están cifrados en los discos del servidor, pero el servidor sigue teniendo las claves para descifrarlos. El cifrado de extremo a extremo significa que solo tú (los extremos) tienes las claves — el servidor nunca tiene acceso al texto plano.
¿Pueden los empleados de Worklist ver mis datos?
No. Nuestro backend está diseñado para no descifrar nunca los datos de usuario. Ni siquiera los administradores de bases de datos con acceso total a nuestros servidores pueden leer tus listas de trabajo o tareas.
¿Y si quiero exportar mis datos?
Puedes exportar tus datos descifrados en cualquier momento desde la app. Como el descifrado ocurre en tu navegador, obtendrás archivos JSON/CSV legibles — no bloques cifrados.
Referencias y estándares.
Nuestras decisiones criptográficas siguen estándares de la industria y especificaciones revisadas por pares.
- 01 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols — Nuestro estándar de cifrado simétrico
- 02 RFC 9497: OPAQUE Asymmetric PAKE Protocol — Autenticación por contraseña de conocimiento cero
- 03 RFC 9180: Hybrid Public Key Encryption (HPKE) — Intercambio de claves para invitaciones de equipo
- 04 RFC 9106: Argon2 Memory-Hard Function — Derivación de claves basada en contraseña
- 05 NIST SP 800-175B: Guideline for Using Cryptographic Standards — Guía criptográfica federal
- 06 GDPR Article 32: Security of Processing — Requisitos europeos de protección de datos
¿Lista para una privacidad real?
Únete a los equipos que confían en Worklist para mantener su trabajo realmente privado. Empieza tu prueba gratuita — sin tarjeta de crédito.
Empezar prueba gratuita¿Preguntas de seguridad? Escríbenos a security@worklist.app