Modéliser les menaces d’un coffre-fort d’identifiants avant la bêta

Avant que PulsVault n’entre en bêta, nous nous sommes assis pour lister qui pourrait l’attaquer et comment. Voici une version abrégée de cet exercice, y compris ce qu’il a changé.

Méthode

Nous avons utilisé un passage simple de type STRIDE. Pour chaque partie du système (client, API de synchronisation, stockage, récupération de compte), nous avons demandé ce qu’un attaquant pourrait usurper, altérer, lire ou perturber. Puis nous avons classé selon la gravité du résultat, pas selon sa probabilité ressentie.

Les attaquants que nous avons anticipés

Quelqu’un qui vole notre base de données

Le cas le plus important. Comme les éléments sont chiffrés sur l’appareil, une copie de la base ne livre que du texte chiffré et des sels. La recherche hors ligne de mots de passe maîtres reste possible, c’est pourquoi le coût de dérivation de la clé et une vérification de robustesse minimale du mot de passe comptent.

Quelqu’un qui lit le trafic

TLS partout, et la charge utile est déjà chiffrée avant d’entrer dans la connexion. Une configuration TLS défaillante divulguerait des métadonnées, pas des contenus.

Un initié malveillant ou curieux

Nous ne pouvons pas lire le contenu des coffres, mais nous pouvons voir les métadonnées des comptes. Nous avons réduit ce que nous journalisons et restreint qui peut interroger les données de production.

Les attaquants que nous avons écartés

Nous ne nous défendons ni contre un logiciel malveillant sur un appareil déverrouillé, ni contre un utilisateur qui saisit son mot de passe maître sur une page d’hameçonnage. Nous le disons dans la documentation plutôt que de laisser entendre le contraire.

Ce que l’exercice a changé

1. La récupération est devenue côté client. Notre première conception prévoyait une réinitialisation par e-mail qui aurait obligé le serveur à détenir une clé de récupération. Cela aurait brisé tout le modèle, donc les codes de récupération sont générés et conservés par l’utilisateur.
2. Les jetons de session ont eu des durées de vie plus courtes. Un jeton volé ne doit pas rester utile longtemps.
3. Les conflits de synchronisation ont cessé d’écraser les données. Un client malveillant ou défectueux pouvait remplacer un bon élément par un mauvais. Le serveur conserve désormais un court historique de versions.

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

Ce qui reste ouvert

Les coffres d’équipe partagés sont plus difficiles : la distribution des clés entre les membres est la partie de la conception à laquelle nous faisons le moins confiance. Nous les gardons en bêta jusqu’à ce qu’ils aient été examinés par quelqu’un d’extérieur à la société.

Pourquoi publier tout cela

Un modèle de menaces qui vit dans la tête d’une seule personne ne sert pas à grand-chose. Le mettre par écrit nous a donné une liste contre laquelle tester, et offre aux utilisateurs un moyen de juger si nos priorités correspondent aux leurs.