Über vertrauenswürdige Geräte

Wenn ein Benutzer sich mit SSO auf einem bereits vertrauenswürdigen Gerät authentifiziert:

1. Der vom Server an den Client gesendete öffentlich verschlüsselte Benutzerschlüssel, der eine verschlüsselte Version des Kontoverschlüsselungsschlüssels ist, der zum Entschlüsseln von Tresor-Daten verwendet wird.

2. Der Geräteschlüssel-verschlüsselter privater Schlüssel des Benutzers, dessen unverschlüsselte Version benötigt wird, um den öffentlichen Schlüssel-verschlüsselten Benutzerschlüssel zu entschlüsseln, wird vom Server an den Client gesendet.

3. Der Client entschlüsselt den Geräteschlüssel-verschlüsselten privaten Schlüssel mit dem Geräteschlüssel, der niemals den Client verlässt.

4. Der jetzt unverschlüsselte Gerät Privatschlüssel wird verwendet, um den mit dem öffentlichen Schlüssel verschlüsselten Benutzerschlüssel zu entschlüsseln, was in dem Verschlüsselungsschlüssel des Benutzerkontos resultiert.

5. Der Verschlüsselungsschlüssel des Benutzerkontos entschlüsselt die Daten im Tresor.

Wenn ein Benutzer sich mit SSO authentifiziert und sich dafür entscheidet, seinen Tresor mit einem nicht vertrauenswürdigen Gerät zu entschlüsseln (d.h. ein Gerätesymmetrischer Schlüssel existiert nicht auf diesem Gerät), muss er eine Methode zur Genehmigung des Geräts auswählen und kann es optional für die zukünftige Nutzung ohne weitere Genehmigung als vertrauenswürdig einstufen. Was als nächstes passiert, hängt von der ausgewählten Option ab:

• Von einem anderen Gerät aus genehmigen :

  1. Der in

     diesem Dokument
     beschriebene Prozess wird ausgelöst, was dazu führt, dass der Client den Verschlüsselungsschlüssel für das Konto erhalten und entschlüsselt hat.

  2. Der Benutzer kann jetzt seine Tresor Daten mit dem entschlüsselten Konto-Verschlüsselungsschlüssel entschlüsseln. Wenn sie sich entschieden haben, dem Gerät zu vertrauen, wird das Vertrauen mit dem Client hergestellt, wie im Onboarding Tab beschrieben.

• Administrator Genehmigung anfordern

  1. Der initiierende Client sendet eine POST-Anfrage, die die E-Mail-Adresse des Kontos, einen einzigartigen auth-request öffentlichen Schlüsselª und einen Zugangscode enthält, an eine Authentifizierungsanforderungstabelle in der Bitwarden-Datenbank.

  2. Administratoren können die Anfrage auf der Gerät-Freigabeseite

     genehmigen oder ablehnen
     .

  3. Wenn die Anfrage von einem Administrator genehmigt wird, verschlüsselt der genehmigende Client den Verschlüsselungsschlüssel des Benutzerkontos mit dem im Antrag enthaltenen auth-request öffentlichen Schlüssel.

  4. Der genehmigende Client stellt dann den verschlüsselten Kontoschlüssel in den Authentifizierungsanforderungsdatensatz und markiert die Anforderung als erfüllt.

  5. Der initiierende Client GETs den verschlüsselten Konto-Verschlüsselungsschlüssel und entschlüsselt ihn lokal mit dem Auth-Anfrage-Privatschlüssel.

  6. Mit dem entschlüsselten Verschlüsselungsschlüssel des Kontos wird das Vertrauen mit dem Client hergestellt, wie im Onboarding Tab beschrieben.

ª - Auth-Anforderung öffentlicher und privater Schlüssel werden einzigartig für jede Anfrage ohne Zugangsdaten generiert und existieren nur so lange wie die Anfrage selbst. Nicht genehmigte Anfragen verfallen nach 1 Woche.

• Genehmigen mit Master-Passwort

  1. Der Verschlüsselungsschlüssel des Benutzerkontos wird abgerufen und entschlüsselt, wie im Abschnitt Benutzerzugangsdaten des

     Sicherheits-Whitepapers
     dokumentiert.

  2. Mit dem entschlüsselten Verschlüsselungsschlüssel des Kontos wird das Vertrauen zum Client hergestellt, wie im Onboarding Tab beschrieben.

Wenn ein Benutzer seinen

1. Der Benutzerschlüssel-verschlüsselter öffentlicher Schlüssel wird vom Server an den Client gesendet und anschließend mit dem alten Konto-Verschlüsselungsschlüssel (auch bekannt als) entschlüsselt. Benutzerschlüssel), was zur Gerät-Öffentlicher Schlüssel führt.

2. Der neue Verschlüsselungsschlüssel des Benutzerkontos wird mit dem unverschlüsselten öffentlichen Schlüssel des Geräts verschlüsselt und der resultierende Wert wird als neuer öffentlich verschlüsselter Benutzerschlüssel an den Server gesendet.

3. Der öffentliche Schlüssel des Geräts wird mit dem neuen Verschlüsselungsschlüssel des Benutzerkontos verschlüsselt und der resultierende Wert wird als neuer Benutzerschlüssel-verschlüsselter öffentlicher Schlüssel an den Server gesendet.

4. Vertrauenswürdige Verschlüsselungsschlüssel für Geräte für alle anderen Geräte, die auf dem Server gespeichert sind, werden für den Benutzer gelöscht. Dies lässt nur die drei erforderlichen Schlüssel (Öffentlicher Schlüssel-verschlüsselter Benutzerschlüssel, Benutzerschlüssel-verschlüsselter öffentlicher Schlüssel und Geräteschlüssel-verschlüsselter privater Schlüssel, der durch diesen Prozess nicht geändert wurde) für dieses einzelne Gerät auf dem Server bestehen.

Jeder jetzt nicht vertrauenswürdige Client muss das Vertrauen durch eine der in der Genehmigen Tab beschriebenen Methoden wiederherstellen.