Compartir registros

Passwork ofrece tres formas de compartir registros: acceso a la bóveda, transferencia directa de registros y enlaces externos.

Resumen de métodos de compartición

Método	Destinatario	Cuenta requerida	Clave de protección
Acceso a la bóveda	Usuario de Passwork	✓	Clave RSA del destinatario
Transferencia directa de registro	Usuario de Passwork	✓	Clave RSA del destinatario
Enlace externo	Cualquier persona	—	Clave de enlace en la URL

---

Uso compartido interno (entre usuarios)

Otorgar acceso a la bóveda

Al añadir un usuario a una bóveda, se produce un intercambio de claves criptográficas.

Proceso de otorgamiento de acceso:

1. El propietario de la bóveda inicia la adición del usuario B
2. El servidor devuelve la clave pública RSA del usuario B
3. El propietario descifra la clave de bóveda con su clave privada RSA (WebCrypto)
4. El propietario cifra la clave de bóveda con la clave pública RSA del usuario B (WebCrypto)
5. La copia cifrada de la clave se envía al servidor
6. El servidor guarda la copia vinculada al usuario B
7. El usuario B obtiene acceso a la bóveda en su próximo inicio de sesión

Importante: El servidor solo ve claves cifradas. Solo el propietario de la clave privada RSA correspondiente puede descifrarlas.

Proceso del propietario

1. Seleccionar el usuario al que otorgar acceso
2. Obtener la clave pública RSA de ese usuario
3. Cifrar la clave de bóveda con la clave pública del destinatario (RSA-OAEP)
4. Enviar la copia cifrada al servidor

Proceso del destinatario

1. Al iniciar sesión, el destinatario ve la nueva bóveda en la lista
2. Descarga la copia cifrada de la clave de bóveda
3. La descifra con su clave privada RSA (WebCrypto)
4. Obtiene acceso a todos los registros de la bóveda

Niveles de acceso

Al otorgar acceso, se puede especificar el nivel de permisos:

• Ver — acceso de solo lectura a los registros
• Editar — modificar registros existentes
• Acceso completo — crear, editar, eliminar registros
• Administrador — gestionar permisos de otros usuarios

Zero-Knowledge

El nivel de acceso se controla a nivel de aplicación. Criptográficamente, todos los usuarios con acceso a la bóveda tienen la misma clave. La diferenciación de permisos se aplica mediante la lógica del servidor.

---

Transferencia directa de registro (sección Bandeja de entrada)

Un registro puede transferirse a un usuario específico sin añadirlo a la bóveda.

Proceso de transferencia directa:

1. El remitente descifra la clave de registro (mediante la clave de bóveda, AES-256-CBC)
2. El remitente solicita la clave pública RSA del destinatario
3. El remitente cifra la clave de registro con la clave pública RSA del destinatario (WebCrypto)
4. La copia cifrada de la clave se envía al servidor
5. El registro aparece en la sección «Bandeja de entrada» del destinatario
6. El destinatario descifra la clave de registro con su clave privada RSA

Diferencia con el acceso a la bóveda: Se transfiere la clave del registro específico, no la clave de la bóveda. El destinatario no ve otros registros en la bóveda.

---

Revocación de acceso

Al revocar el acceso a una bóveda o registro:

1. El servidor elimina la copia cifrada de la clave del usuario
2. El usuario ya no puede obtener la clave del servidor
3. Los datos se vuelven inaccesibles a través de la interfaz

Limitación criptográfica

Es importante comprender: Si un usuario obtuvo previamente la clave de la bóveda/registro y la guardó localmente, teóricamente podría descifrar los datos si tiene el contenido cifrado (por ejemplo, de una copia de seguridad de la base de datos).

Esta es una limitación fundamental de la criptografía de clave compartida. Para una protección completa tras la revocación de acceso, se recomienda:

• Cambiar las contraseñas en los registros críticos
• Si es necesario — recrear la bóveda con una nueva clave

---

Enlaces externos

Los enlaces externos permiten compartir un registro con alguien que no tiene cuenta de Passwork.

Cómo funciona

Creación de un enlace (propietario):

1. El propietario selecciona el registro a compartir
2. Se genera una clave de enlace aleatoria (256 bits) en el cliente
3. Se crea una copia de los campos seleccionados del registro
4. La copia se cifra con la clave de enlace (AES-256-CBC)
5. Se envía al servidor: copia cifrada + hash de la clave + configuración
6. El servidor genera un token de enlace (43 caracteres)
7. El propietario recibe una URL como https://passwork.example/g/p/{token}

Apertura de un enlace (destinatario):

1. El propietario envía la URL al destinatario (correo electrónico, mensajería)
2. El destinatario abre la URL
3. El navegador envía una solicitud al servidor (solo el token, sin la clave)
4. El servidor verifica el token (existe, no ha expirado, no es de un solo uso)
5. El servidor devuelve los datos cifrados
6. JavaScript extrae la clave de la parte hash de la URL (#code=...)
7. Los datos se descifran con la clave de enlace en el navegador (AES-256-CBC)
8. El destinatario ve el registro

Token de enlace y clave

El enlace externo contiene dos componentes:

Parámetro	Token de enlace	Clave de enlace
Propósito	Identificador del enlace	Cifrado de datos
Ubicación	Ruta de la URL (/g/p/{token})	Hash de la URL (#code={key})
Generación	En el servidor	En el cliente
Longitud	43 caracteres	100 caracteres → 256 bits
Alfabeto	A-Z, a-z, 0-9 (62)	A-Z, a-z, 0-9, @, ! (64)
Entropía de entrada	~256 bits	~596 bits
Visible para el servidor	✓	— (solo el hash)

Transformación de clave: La cadena de 100 caracteres se convierte en una clave AES de 256 bits mediante una función de derivación de clave (KDF), de forma similar a las claves de bóveda, registro y archivo adjunto.

Solo con CSE habilitado

La clave de enlace del lado del cliente se genera solo cuando el cifrado del lado del cliente está habilitado (CSE). Si CSE está deshabilitado, los datos del enlace no se cifran en el cliente — solo se aplica el cifrado del lado del servidor.

Formato de URL:

https://passwork.example.com/g/p/{token}#code={link_key}

El fragmento no se envía al servidor

La clave de enlace se pasa en la parte hash de la URL (después de #). Según el estándar HTTP, el fragmento (parte de la URL después de #) nunca se envía al servidor — solo lo procesa el navegador en el lado del cliente.

Esto significa:

• Al seguir el enlace, el servidor solo ve {token}, pero no ve la clave
• La clave solo está disponible para el código JavaScript en el navegador del destinatario
• Incluso si la solicitud es interceptada en el lado del servidor, la clave permanece protegida
• El principio Zero-Knowledge se mantiene a nivel del protocolo HTTP

Almacenamiento de la clave en el servidor

La clave de enlace no se almacena en el servidor en texto plano:

• El servidor guarda únicamente el hash SHA-256 de la clave para verificar la corrección al abrir
• Al abrir el enlace, el cliente calcula el hash de la clave introducida y lo envía al servidor
• El servidor compara los hashes y devuelve los datos cifrados

Estructura de datos del enlace

Almacenado en el servidor:

Datos	Cifrado
Identificador del enlace (token)	—
Copia de datos del registro	Con clave de enlace + clave del servidor
Hash SHA-256 de la clave	Con clave del servidor
Configuración (TTL, un solo uso)	Con clave del servidor

Campos del registro copiados

Al crear un enlace, se copian los siguientes:

Campo	Incluido
Nombre	✓
Inicio de sesión	Sí (opcional)
Contraseña (cifrada)	✓
URL	Sí (opcional)
Descripción	Sí (opcional)
Campos personalizados	Sí (opcional)
Archivos adjuntos	Sí (opcional, metadatos + claves)

Configuración del enlace

Configuración	Descripción
Tiempo de vida (TTL)	El enlace se elimina automáticamente después del tiempo especificado
Uso único	El enlace se invalida después de la primera visualización
Protección con contraseña	Contraseña adicional para el acceso
Selección de campos	Qué campos del registro incluir en el enlace

---

Seguridad de los enlaces externos

Principio Zero-Knowledge

• La clave de enlace se pasa en la parte hash de la URL (#code=...) — el navegador no la envía al servidor
• Al seguir el enlace, el servidor solo ve el token, la clave permanece únicamente en el navegador
• El servidor almacena solo el hash de la clave para verificación de corrección
• Los datos en el servidor están cifrados y no pueden leerse sin la clave

Modelo de amenazas

Amenaza	Protección
Interceptación de la solicitud del servidor	La clave en la parte hash no se envía al servidor
Interceptación de la URL completa	Requiere interceptación del lado del cliente
Compromiso del servidor	Los datos están cifrados, la clave no está en el servidor
Fuerza bruta del token	256 bits de entropía hacen la fuerza bruta imposible
Reutilización	Enlaces de un solo uso
Registro de URLs en el servidor	Los registros contienen solo el token, sin la clave

Recomendaciones

1. Para datos críticos — utilice enlaces de un solo uso
2. Para acceso temporal — establezca un TTL corto
3. Para protección adicional — transmita la clave por un canal separado
4. Para auditoría — rastree el uso de enlaces en los registros

---

Inclusión de archivos adjuntos en enlaces

Al crear un enlace con archivos adjuntos:

Estructura del registro original: clave de registro, archivo (cifrado con clave de archivo adjunto), clave de archivo adjunto (cifrada con clave de registro).

Al crear el enlace: se genera la clave de enlace, la clave de archivo adjunto se recifra con la clave de enlace, los datos del archivo permanecen sin cambios en el servidor, el enlace incluye: ID del archivo + nombre + clave recifrada.

Al abrir el enlace: el destinatario descifra la clave de archivo adjunto con la clave de enlace, solicita el archivo al servidor por ID, descifra el archivo con la clave de archivo adjunto.

---

Comparación de métodos de compartición

Criterio	Acceso a la bóveda	Transferencia directa	Enlace externo
Cuenta requerida	✓	✓	—
Acceso a todos los registros	✓	— (solo uno)	— (solo uno)
Auditoría de acceso	✓	✓	⚠️ Limitada
Se puede revocar	✓	✓	✓
Zero-Knowledge	✓	✓	✓
Sincronización de cambios	✓	⚠️	— (copia de datos)