Threat Modelling eines Zugangsdaten-Tresors vor der Beta

Bevor PulsVault in die Beta ging, haben wir uns hingesetzt und aufgelistet, wer es angreifen könnte und wie. Dies ist eine gekürzte Fassung dieser Übung, einschließlich dessen, was sie verändert hat.

Methode

Wir haben einen einfachen Durchgang im Stil von STRIDE gemacht. Für jeden Teil des Systems (Client, Sync-API, Speicher, Konto-Wiederherstellung) haben wir gefragt, was ein Angreifer vortäuschen, manipulieren, lesen oder stören könnte. Anschließend haben wir danach gewichtet, wie schlimm das Ergebnis wäre – nicht danach, wie wahrscheinlich es sich anfühlte.

Angreifer, auf die wir uns vorbereitet haben

Jemand, der unsere Datenbank stiehlt

Der wichtigste Fall. Da Einträge auf dem Gerät verschlüsselt werden, liefert ein Datenbank-Dump Chiffretext und Salts. Offline-Erraten von Master-Passwörtern bleibt möglich, weshalb der Aufwand der Schlüsselableitung und eine Prüfung der Mindest-Passwortstärke wichtig sind.

Jemand, der den Datenverkehr mitliest

TLS überall, und die Nutzdaten sind bereits verschlüsselt, bevor sie in die Verbindung gelangen. Eine fehlerhafte TLS-Konfiguration würde Metadaten preisgeben, nicht Inhalte.

Ein böswilliger oder neugieriger Insider

Wir können die Inhalte des Tresors nicht lesen, aber wir sehen Konto-Metadaten. Wir haben reduziert, was wir protokollieren, und eingeschränkt, wer Produktivdaten abfragen darf.

Angreifer, die wir ausgeschlossen haben

Wir verteidigen uns nicht gegen Malware auf einem entsperrten Gerät oder gegen Nutzer, die ihr Master-Passwort auf einer Phishing-Seite eingeben. Das sagen wir in der Dokumentation, statt etwas anderes anzudeuten.

Was die Übung verändert hat

1. Die Wiederherstellung wurde clientseitig. Unser erster Entwurf sah ein E-Mail-basiertes Zurücksetzen vor, bei dem der Server einen Wiederherstellungsschlüssel hätte halten müssen. Das hätte das gesamte Modell gebrochen, daher werden Wiederherstellungscodes vom Nutzer erzeugt und aufbewahrt.
2. Sitzungs-Tokens erhielten kürzere Laufzeiten. Ein gestohlenes Token sollte nicht lange nützlich sein.
3. Sync-Konflikte überschreiben nicht mehr. Ein böswilliger oder fehlerhafter Client könnte einen guten Eintrag durch einen schlechten ersetzen. Der Server führt jetzt eine kurze Versionshistorie.

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

Was noch offen ist

Gemeinsame Team-Tresore sind schwieriger: Die Schlüsselverteilung zwischen Mitgliedern ist der Teil des Designs, dem wir am wenigsten vertrauen. Wir halten sie in der Beta, bis sie von jemandem außerhalb des Unternehmens geprüft wurden.

Warum wir das veröffentlichen

Ein Bedrohungsmodell, das nur im Kopf einer Person existiert, nützt wenig. Es aufzuschreiben gab uns eine Liste zum Testen und gibt Nutzern die Möglichkeit zu beurteilen, ob unsere Prioritäten zu ihren passen.