Modelar las amenazas de una caja fuerte de credenciales antes de la beta

Antes de que PulsVault entrara en beta nos sentamos a enumerar quién podría atacarlo y cómo. Esta es una versión resumida de ese ejercicio, incluido lo que cambió.

Método

Usamos un repaso sencillo al estilo STRIDE. Para cada parte del sistema (cliente, API de sincronización, almacenamiento, recuperación de cuenta) nos preguntamos qué podría suplantar, manipular, leer o interrumpir un atacante. Después las ordenamos por la gravedad del resultado, no por lo probables que parecían.

Atacantes para los que nos preparamos

Alguien que robe nuestra base de datos

El caso más importante. Como los elementos se cifran en el dispositivo, un volcado de la base de datos solo ofrece texto cifrado y sales. Adivinar contraseñas maestras sin conexión sigue siendo posible, por lo que importan el coste de derivación de claves y una comprobación de robustez mínima de la contraseña.

Alguien que lea el tráfico

TLS en todas partes, y la carga útil ya está cifrada antes de entrar en la conexión. Una configuración TLS defectuosa filtraría metadatos, no contenido.

Un empleado malintencionado o curioso

No podemos leer el contenido de las cajas fuertes, pero sí vemos los metadatos de las cuentas. Redujimos lo que registramos y restringimos quién puede consultar los datos de producción.

Atacantes que descartamos

No nos defendemos del malware en un dispositivo desbloqueado, ni de un usuario que escribe su contraseña maestra en una página de phishing. Lo decimos en la documentación en lugar de insinuar lo contrario.

Qué cambió con el ejercicio

1. La recuperación pasó al cliente. Nuestro primer diseño tenía un restablecimiento por correo que habría exigido que el servidor guardara una clave de recuperación. Habría roto todo el modelo, así que los códigos de recuperación los genera y conserva el usuario.
2. Los tokens de sesión pasaron a tener una vida más corta. Un token robado no debería servir durante mucho tiempo.
3. Los conflictos de sincronización dejaron de sobrescribir. Un cliente malicioso o con errores podía reemplazar un elemento bueno por uno malo. Ahora el servidor conserva un breve historial de versiones.

sync:
  keep_versions: 10
  max_item_bytes: 65536
  require_client_version: ">=0.9.0"

Lo que sigue abierto

Las cajas fuertes de equipo compartidas son más difíciles: la distribución de claves entre miembros es la parte del diseño en la que menos confiamos. Las mantendremos en beta hasta que las haya revisado alguien ajeno a la empresa.

Por qué publicarlo

Un modelo de amenazas que vive en la cabeza de una persona sirve de poco. Ponerlo por escrito nos dio una lista contra la que probar, y ofrece a los usuarios una forma de juzgar si nuestras prioridades coinciden con las suyas.