Cifrado del lado del servidor vs. del lado del cliente: ¿en qué modelo deberías confiar?

El cifrado del lado del servidor cifra los datos en el servidor después de recibir el texto plano, lo que requiere confiar en el proveedor del servicio. El cifrado del lado del cliente cifra los datos en tu navegador antes de enviarlos, de modo que el servidor nunca ve el texto plano. Para compartir secretos, el cifrado del lado del cliente es más seguro porque elimina al servicio como punto de confianza: incluso un servidor comprometido no puede leer tus datos.

Esta publicación compara ambos enfoques: cómo funcionan, qué te pide confiar cada uno y dónde están las verdaderas compensaciones. No es un argumento a favor de un lado: es un marco para evaluar qué modelo se ajusta a tu modelo de amenazas.

Para un resumen rápido de por qué importa el cifrado del lado del cliente, consulta nuestra publicación anterior. Para un vistazo detallado a la implementación específica de Vaulted, consulta nuestro análisis a fondo del conocimiento cero.

Cómo funciona el cifrado del lado del servidor

En el modelo del lado del servidor, el servicio se encarga del cifrado en tu nombre. El flujo típico:

Introduces un secreto en el navegador
Tu navegador envía el texto plano al servidor a través de TLS
El servidor cifra los datos usando una clave que él gestiona
El texto cifrado se almacena en la base de datos
Cuando el destinatario solicita el secreto, el servidor lo descifra y devuelve el texto plano

La clave de cifrado nunca abandona el servidor. Podría residir en un módulo de seguridad de hardware (HSM), un servicio de gestión de claves en la nube (KMS) o un archivo de configuración, pero el servidor la controla por completo.

El modelo de confianza del lado del servidor

Con el cifrado del lado del servidor, estás confiando en:

El operador del servicio para que no lea tus datos (tiene la clave y el texto plano en memoria durante el cifrado/descifrado)
La infraestructura para que no sea vulnerada (un servidor comprometido expone tanto las claves como los datos)
Los empleados del operador para que no abusen del acceso (cualquiera con acceso al servidor puede leer secretos potencialmente)
La jurisdicción legal para que no obligue a la divulgación (se puede forzar al operador a entregar los datos porque posee las claves)
Los registros y la monitorización del servidor para que no capturen texto plano (los marcos de registro pueden grabar datos sensibles de forma involuntaria)

Este no es necesariamente un mal modelo. Muchos servicios lo usan con éxito: el almacenamiento en la nube, los proveedores de correo electrónico y los servicios de bases de datos se apoyan en el cifrado del lado del servidor. La cuestión es si la compensación se ajusta a tu caso de uso.

Cómo funciona el cifrado del lado del cliente

En el modelo del lado del cliente, el cifrado ocurre en el navegador antes de que ningún dato llegue al servidor. El flujo es diferente:

Introduces un secreto en el navegador
El navegador genera una clave de cifrado y cifra los datos localmente
Solo se envía el texto cifrado al servidor
La clave de cifrado se entrega al destinatario a través de un canal independiente (normalmente el fragmento de la URL)
El navegador del destinatario descifra el texto cifrado localmente

El servidor nunca ve el texto plano y nunca posee la clave de cifrado. Almacena y recupera bloques cifrados, nada más.

Vaulted usa este modelo. Cada secreto recibe una clave AES-256-GCM nueva. La clave se coloca en el fragmento de la URL (#), que los navegadores nunca incluyen en las solicitudes HTTP según el RFC 3986. El servidor recibe el texto cifrado y un IV aleatorio de 12 bytes para almacenarlo, pero la clave permanece por completo en el enlace compartido entre el remitente y el destinatario.

El modelo de confianza del lado del cliente

Con el cifrado del lado del cliente, estás confiando en:

El navegador para que implemente la criptografía correctamente (la Web Crypto API delega en motores criptográficos nativos como BoringSSL o NSS)
El código de la aplicación para que realmente realice el cifrado del lado del cliente (puedes verificarlo inspeccionando las solicitudes de red)
El canal de entrega del enlace para que sea seguro (cualquiera que tenga la URL completa, incluido el fragmento, puede descifrar el secreto)
El dispositivo del destinatario para que no esté comprometido (tras el descifrado, el malware o la captura de pantalla pueden acceder al texto plano)

No estás confiando en el servidor, el operador del servicio, sus empleados ni su jurisdicción legal. El servidor es un relé de almacenamiento para datos cifrados que no puede leer.

Comparación de las compensaciones

Ningún modelo es universalmente mejor. Cada uno establece compensaciones diferentes entre seguridad, usabilidad y riqueza de funciones.

Propiedades de seguridad

Propiedad	Lado del servidor	Lado del cliente
Exposición ante una brecha del servidor	Claves + texto cifrado expuestos	Solo el texto cifrado expuesto (inútil sin las claves)
El operador puede leer los datos	Sí (posee las claves)	No (nunca tiene las claves)
Riesgo de coacción legal	El operador puede cumplir (tiene acceso)	El operador no puede cumplir (no tiene acceso)
Riesgo de interceptación del enlace	No aplica (no hay clave en el enlace)	URL completa = acceso completo (mitigado por la frase de contraseña)
Hombre en el medio	TLS protege el tránsito; el servidor ve el texto plano	TLS protege el texto cifrado; la clave en el fragmento nunca se envía

Propiedades de usabilidad

Propiedad	Lado del servidor	Lado del cliente
Carga de gestión de claves	Ninguna para el usuario (el servidor se encarga)	El usuario debe compartir el enlace de forma segura
Recuperación de contraseña	Posible (el servidor posee las claves)	No es posible (las claves solo están en el enlace)
Búsqueda e indexación	El servidor puede buscar el texto plano	No es posible sin descifrar
Flexibilidad para compartir	El servidor puede recifrar para nuevos destinatarios	Requiere un enlace nuevo por destinatario
Acceso sin conexión	Requiere conexión al servidor para descifrar	Posible si el texto cifrado y la clave se almacenan localmente

Compensaciones de funciones

Función	Lado del servidor	Lado del cliente
Registro de auditoría del contenido	Posible	No es posible (el servidor no puede leer el contenido)
Políticas basadas en el contenido	Posible (DLP, escaneo de cumplimiento)	No es posible sin descifrar
Rotación de claves	El servidor puede recifrar con claves nuevas	Requiere regenerar y volver a compartir los enlaces
Control de acceso multiparte	El servidor puede gestionar claves por usuario	Cada destinatario necesita la clave directamente
Garantía de conocimiento cero	No	Sí

Cuándo es aceptable el cifrado del lado del servidor

El cifrado del lado del servidor es una opción razonable cuando:

Confías en el operador del servicio y en sus prácticas de seguridad
Necesitas funciones que requieren acceso del servidor a los datos (búsqueda, compartir, escaneo de cumplimiento)
La sensibilidad de los datos no justifica el coste de usabilidad del cifrado del lado del cliente
Operas en un entorno regulado donde las certificaciones de cumplimiento del operador importan más que las garantías de conocimiento cero
La complejidad de la gestión de claves debe ser manejada por el servicio, no por el usuario

Los servicios de almacenamiento en la nube, el correo electrónico empresarial y el cifrado de bases de datos gestionadas usan este modelo de forma eficaz.

Cuándo es necesario el cifrado del lado del cliente

El cifrado del lado del cliente se vuelve necesario cuando:

No puedes o no deberías confiar tus datos al operador del servicio
Los datos son lo bastante sensibles como para que una brecha del servidor no deba exponer el texto plano
Necesitas una garantía de conocimiento cero: una prueba matemática de que el servidor no puede leer tus datos
Los requisitos legales o de cumplimiento exigen que el operador del servicio no tenga acceso al contenido
Quieres protección contra amenazas internas en el proveedor del servicio

Compartir secretos es uno de los casos de uso más sólidos para el cifrado del lado del cliente. Los datos son inherentemente sensibles (contraseñas, claves de API, credenciales), el intercambio es transitorio (con límite de vistas y límite de tiempo) y la relación de confianza es mínima (puede que no conozcas ni confíes en el operador del servicio).

Cómo aborda esto Vaulted

Vaulted usa exclusivamente el cifrado del lado del cliente. Cada secreto se cifra en el navegador con una clave AES-GCM nueva antes de que ningún dato llegue al servidor. La clave viaja únicamente en el fragmento de la URL, y la protección opcional con frase de contraseña añade una segunda capa mediante la derivación de claves PBKDF2 y el encapsulado de la clave AES-KW.

El servidor almacena el texto cifrado con un tiempo de vida y un contador de vistas. No puede descifrar, buscar ni inspeccionar el contenido. Una brecha completa de la base de datos solo produce bloques cifrados, computacionalmente inútiles sin las claves que existen únicamente en los enlaces compartidos.

Para los detalles criptográficos completos —generación de claves, manejo del IV, encapsulado con frase de contraseña y las llamadas exactas a la Web Crypto API— consulta nuestro análisis a fondo del cifrado de conocimiento cero.

Cómo tomar tu decisión

El modelo de cifrado adecuado depende de qué estés protegiendo y en quién estés dispuesto a confiar.

Si necesitas funciones como búsqueda, recuperación o gestión centralizada de claves, el cifrado del lado del servidor es la opción práctica. Si necesitas una garantía de que nadie —ni el servicio, ni sus empleados, ni una orden judicial— pueda leer tus datos, el cifrado del lado del cliente es el único modelo que la ofrece.

Para compartir secretos, la respuesta es sencilla: los datos son sensibles, la interacción es breve y cuantas menos partes puedan acceder al texto plano, mejor.

¿Listo para compartir un secreto con cifrado de conocimiento cero? Crea un secreto en Vaulted: tus datos nunca salen de tu navegador sin cifrar.

Relacionado

Por qué importa el cifrado del lado del cliente: el argumento a favor de cifrar en el navegador
Cifrado de conocimiento cero: cómo Vaulted mantiene tus secretos privados: análisis a fondo de la implementación criptográfica
Seguridad en Vaulted: resumen de nuestro modelo de seguridad