Single Sign-On-Verfahren bei 1Password: Ein technischer Deep Dive

by Rick van Galen & Aidan Woods
January 20, 2023 - 15 min
Related Categories
Kürzlich haben wir angekündigt, dass Kunden von 1Password Business ihre Konten bald mit Okta per Single Sign-On (SSO) entsperren können.
Seitdem haben wir mit vielen von Ihnen gesprochen, die sich mehr technische Details wünschen – und diesem Wunsch kommen wir gerne nach. Wir lieben fundierte Deep Dives, daher werfen wir nun einen genaueren Blick auf die Überlegungen hinter unserem Ansatz.
In diesem Artikel werfen wir einen Blick auf die technischen Hintergründe des SSO-Logins bei 1Password. Wir erläutern, warum es sich dabei um eine komplexe Herausforderung handelt und wie wir eine Lösung entwickelt haben, die dem 1Password-Sicherheitsversprechen gerecht wird – einschließlich der Frage, wie wir sicherstellen, dass niemand außer Ihnen selbst auf die Daten in Ihren Tresoren zugreifen kann.
Zum Schluss schauen wir uns an, was der SSO-Login für die Sicherheit Ihres 1Password-Kontos bedeutet und welche Entwicklungen künftig geplant sind.
SSO und das Problem der Entschlüsselung
Die meisten Web-Services müssen „nur“ Authentifizierung und Autorisierung lösen – also feststellen, ob ein Nutzer tatsächlich der ist, für den er sich ausgibt, und ob er Zugriff auf eine bestimmte Ressource haben darf. Für solche Dienste ist Single Sign-On (SSO) eine ideale Lösung für Unternehmen: Es ermöglicht eine zentrale Verwaltung von Zugriffsrechten sowie die Durchsetzung starker Authentifizierung, klarer Richtlinien und umfassender Auditierbarkeit.
Auch 1Password muss Authentifizierungs- und Autorisierungsprobleme lösen – doch das Passwort, das Sie heute für Ihr 1Password-Konto verwenden, hat noch eine weitere Aufgabe: Es wird benötigt, um Ihre gespeicherten Passwörter zu entschlüsseln. Ihr Kontopasswort stellt sicher, dass nur Sie selbst dies tun können.
Bei der Entwicklung von 1Password mussten wir berücksichtigen, dass unsere Server theoretisch eines Tages kompromittiert werden könnten. Mit der neuen Möglichkeit, 1Password per Single Sign-On zu entsperren, wollten wir unserem Versprechen zur sicheren Entschlüsselung treu bleiben. Unsere SSO-Implementierung stellt sicher, dass weder 1Password noch der Identity Provider Zugriff auf Ihre Passwörter erhalten können.
Die Herausforderung besteht darin, dass klassische Single-Sign-On-Verfahren nicht darauf ausgelegt sind, dieses Entschlüsselungsproblem zu lösen. Gängige Protokolle für die Anmeldung per SSO – etwa OAuth, OIDC oder SAML – bieten keine Möglichkeit, dass Nutzende am Ende einen Entschlüsselungsschlüssel besitzen, den nur sie selbst kennen.
Die 1Password-Lösung – so funktioniert sie
Um unserem Sicherheitsversprechen treu zu bleiben, benötigten wir eine Erweiterung des klassischen Single-Sign-On-Verfahrens.
Bei der Nutzung eines SSO-fähigen Kontos erfolgt die Entschlüsselung über das Gerät, auf dem 1Password installiert ist. Dabei wird ein gerätespezifischer Schlüssel verwendet – der sogenannte Device Key, der für jedes Gerät einzigartig ist.
Dieser Device Key wird ausschließlich auf den Geräten der Nutzer gespeichert.
Anmeldung
Der Device Key spielt eine zentrale Rolle beim Anmeldeprozess mit Single Sign-On und unterscheidet sich grundlegend vom bisherigen Entsperrmechanismus.
Bei klassischen Konten mit Kontopasswort und Secret Key übernehmen beide Elemente unterschiedliche Sicherheitsfunktionen:
Das Kontopasswort schützt Ihre Daten auf Ihren Geräten.
Der Secret Key schützt – zusätzlich zum Passwort – Ihre Daten auf den 1Password-Servern.
Anders gesagt:
Ihre Geräte speichern einen starken kryptografischen Schlüssel (den Secret Key), während Ihr Passwort sicherstellt, dass nur Sie 1Password auf Ihrem Gerät entsperren können.
Bei SSO-fähigen Konten bleibt das Gerät weiterhin dafür verantwortlich, einen starken kryptografischen Schlüssel bereitzustellen – in diesem Fall den Device Key.
Der Identity Provider übernimmt hingegen die Aufgabe sicherzustellen, dass nur Sie Ihr 1Password-Konto öffnen können.
Wie der Device Key gespeichert wird, hängt vom jeweiligen Gerätetyp ab. Eine Übersicht über die Unterschiede zwischen Plattformen finden Sie in der entsprechenden Support-Dokumentation.
Kontopasswort und Secret Key erfüllen also weiterhin zwei wichtige, aber unterschiedliche Sicherheitsaufgaben.
Bei klassischen Konten werden Passwort und Secret Key kombiniert, um zwei separate Schlüssel abzuleiten:
einen Authentifizierungsschlüssel
einen Verschlüsselungsschlüssel
Diese Kombination wird als Credential Bundle bezeichnet.
Beide Komponenten sind erforderlich, um dieses Bundle zu erstellen – wodurch Sie sich anmelden und anschließend Ihre Daten entschlüsseln können.
Bei SSO-fähigen Konten wird das Credential Bundle stattdessen aus zwei zufällig generierten Schlüsseln erstellt und anschließend mit dem Device Key verschlüsselt.
Das verschlüsselte Credential Bundle wird auf den 1Password-Servern gespeichert.
Da der Device Key ausschließlich auf Ihren Geräten vorhanden ist, können nur Ihre Geräte dieses Credential Bundle entschlüsseln.
Die 1Password-Server geben dieses verschlüsselte Bundle nur dann an Ihre Geräte frei, wenn Sie sich erfolgreich über Ihren Identity Provider authentifizieren.
Mit einem SSO-aktivierten Konto wird Ihr Credential Bundle stattdessen aus zwei zufällig generierten Schlüsseln erstellt und mit Ihrem gerätespezifischen Schlüssel verschlüsselt. Dieses verschlüsselte Credential Bundle wird anschließend auf den Servern von 1Password gespeichert.
Da der Geräteschlüssel ausschließlich auf Ihrem Gerät gespeichert ist, können nur Ihre Geräte dieses Credential Bundle entschlüsseln. Die 1Password-Server geben das verschlüsselte Credential Bundle nur dann an Ihre Geräte frei, wenn Sie sich erfolgreich über Ihren Identity Provider anmelden.
Schnelles Entsperren mit Biometrie
Da die App in diesem Setup jedes Mal Ihren Identity Provider kontaktieren muss, wenn Sie 1Password entsperren, können SSO-aktivierte Konten standardmäßig nur mit aktiver Internetverbindung genutzt werden.
Ein wichtiger Vorteil von 1Password ist jedoch, dass Passwörter, sichere Notizen und gespeicherte Dokumente auch bei instabiler Verbindung verfügbar bleiben. Damit Secrets auch offline zugänglich sind, nutzt 1Password eine bewährte Funktion der Apps: biometrisches Entsperren.
Nach der Aktivierung können 1Password-Clients biometrische Verfahren verwenden, um Ihr Credential Bundle sowie ein Re-Authentifizierungs-Token sicher auf dem Gerät zu speichern.
Administratoren können das biometrische Entsperren in den Kontoeinstellungen für ihre Nutzer aktivieren. Auf unterstützten Geräten ermöglicht diese Funktion, das Credential Bundle lokal zu speichern und 1Password auch ohne Internetverbindung zu entsperren. Das Re-Authentifizierungs-Token dient dazu, sich erneut beim 1Password-Server zu authentifizieren, damit die Synchronisierung der Tresordaten fortgesetzt werden kann, sobald wieder eine Verbindung besteht.
Biometrisches Entsperren wird unterstützt auf:
macOS mit T2-Chip oder Apple Silicon
Android- und iOS-Geräten mit integrierten Secure Elements
Windows-Geräten mit Windows Hello (Unter Windows wird kein Secure Element verwendet; das Re-Authentifizierungs-Token wird stattdessen während der Laufzeit der App im geschützten Speicher abgelegt.)
Ein Re-Authentifizierungs-Token wird ausschließlich nach erfolgreicher Anmeldung ausgestellt. Es ist durch Sitzungsverschlüsselung geschützt, um seine langfristige Vertraulichkeit selbst bei möglichen TLS-Schwachstellen sicherzustellen – genauso wie andere Kontodaten in 1Password.
Bei jeder Nutzung eines Re-Authentifizierungs-Tokens erfolgt die Übertragung über TLS-gesicherte Verbindungen. Danach gilt das Token als verbraucht und kann nicht erneut verwendet werden. Deshalb wird bei jedem biometrischen Entsperrvorgang automatisch ein neues Re-Authentifizierungs-Token angefordert. Während die App entsperrt ist, fordert sie zudem regelmäßig neue Tokens an, damit 1Password entsprechend den Richtlinien weiterhin entsperrt bleiben kann.
Wenn ein Administrator das biometrische Entsperren aktiviert, wird die Verantwortung für die Authentifizierung eines Nutzers vorübergehend vom Identity Provider auf das Gerät des Nutzers übertragen.
Vertrauenswürdige Geräte
Wenn Sie sich mit einem SSO-basierten Konto registrieren, wird das Gerät, mit dem Sie sich anmelden, automatisch zu Ihrem ersten vertrauenswürdigen Gerät. Ein Gerät gilt als vertrauenswürdig, wenn es über einen Geräteschlüssel verfügt, mit dem Ihr Credential Bundle verschlüsselt wurde – und somit in der Lage ist, Sie anzumelden. Sie haben diesem Gerät also das Vertrauen gegeben, den Login durchzuführen.
Eine zentrale Herausforderung bei der Nutzung von SSO für den Zugriff auf 1Password besteht darin, zusätzliche vertrauenswürdige Geräte einzurichten, ohne die Vertraulichkeit Ihres Credential Bundles zu gefährden. Ihr erstes vertrauenswürdiges Gerät erstellt das Credential Bundle und verschlüsselt es mit seinem eigenen Geräteschlüssel. Weitere Geräte müssen jedoch ebenfalls eine Kopie dieses Credential Bundles erhalten, damit jedes Gerät es mit seinem eigenen Geräteschlüssel verschlüsseln kann.
Wenn Sie sich erstmals auf einem zusätzlichen Gerät über Ihren Identity Provider anmelden, durchläuft dieses Gerät einen Registrierungs- bzw. Enrollment-Prozess. Dabei wird Ihr Credential Bundle sicher von einem bereits vertrauenswürdigen Gerät, das Zugriff darauf hat, auf das neue Gerät übertragen, das bislang keinen Zugriff besitzt. Dadurch kann sich das neue Gerät anmelden, Ihre 1Password-Daten eigenständig entschlüsseln und selbst zu einem vertrauenswürdigen Gerät werden.
Der erste Schritt in diesem Prozess besteht darin, sich über den Identity Provider anzumelden. Dadurch erhalten die 1Password-Server hinreichende Sicherheit darüber, dass Sie versuchen, sich auf einem neuen Gerät anzumelden. Anschließend senden die Server eine Benachrichtigung an alle aktuell vertrauenswürdigen Geräte mit der Bitte, den neuen Anmeldeversuch auf einem dieser Geräte zu bestätigen.
Sobald Sie diese Benachrichtigung auf einem vertrauenswürdigen Gerät erhalten, können Sie den Login genehmigen oder ablehnen. Zur Genehmigung erzeugt das vertrauenswürdige Gerät einen zufälligen Bestätigungscode, den Sie auf dem neuen Gerät eingeben. Mithilfe dieses Codes authentifizieren Ihre Geräte anschließend einen End-to-End-verschlüsselten Handshake, der es dem vertrauenswürdigen Gerät ermöglicht, Ihr Credential Bundle sicher an das neue Gerät zu übertragen.
Sobald das neue Gerät das Credential Bundle erhalten hat, kann es sich bei Ihrem 1Password-Konto anmelden, Ihre Daten entschlüsseln und sich selbst als neues vertrauenswürdiges Gerät registrieren, indem es das Credential Bundle mit seinem eigenen Geräteschlüssel verschlüsselt.
Ende-zu-Ende-Verschlüsselung beim Hinzufügen eines neuen Geräts
Hintergrund und Ziele
Unser Ziel war es, die Einrichtung neuer Geräte für Nutzer möglichst einfach zu gestalten. Eine Möglichkeit zur Absicherung wäre gewesen, Nutzer zur manuellen Eingabe eines 32-Byte-Schlüssels aufzufordern – das ist jedoch wenig benutzerfreundlich. Die Eingabe eines vergleichsweise kurzen Bestätigungscodes ist dagegen deutlich einfacher.
Dies bringt jedoch eine anspruchsvolle sicherheitstechnische Herausforderung mit sich. Um die Kommunikation zwischen Ihren Geräten abzusichern, konnten wir sensible Daten nicht einfach mit einem kurzen Code verschlüsseln – das wäre nicht ausreichend sicher. Stattdessen musste der Bestätigungscode dazu dienen, einen vertrauenswürdigen Kommunikationskanal zu bestätigen, ohne selbst direkt zur Verschlüsselung verwendet zu werden.
Eine Ende-zu-Ende-Verschlüsselung zwischen Ihren Geräten während des Einrichtungsprozesses ist entscheidend, um unser Sicherheitsversprechen einzuhalten: Nur Ihre Geräte sollen in der Lage sein, Ihr Credential Bundle zu entschlüsseln. Da die Server von 1Password diesen Einrichtungsprozess unterstützen, mussten mehrere wichtige Sicherheitsaspekte berücksichtigt werden. Wir haben diesen Austausch so konzipiert, dass er selbst dann sicher bleibt, wenn jemand die Kommunikation zwischen Ihren Geräten speichert oder aktiv manipuliert.
Konkret erfüllt dieser Prozess eine Sicherheitseigenschaft, die als Perfect Forward Secrecy bezeichnet wird.
Die Kommunikation zwischen Ihren Geräten wird dabei durch einen zufällig generierten Code authentifiziert – jedoch nicht mit diesem Code verschlüsselt. Das ist wichtig, um Brute-Force-Angriffe auf den Code selbst zu verhindern. Dadurch wird sichergestellt, dass niemand mit Zugriff auf die Netzwerkkommunikation – auch nicht der 1Password-Server – Ihr Credential Bundle entschlüsseln kann.
Indem der Code ausschließlich zur Authentifizierung des Austauschs verwendet wird, können Ihre Geräte starke ephemere Schlüssel einsetzen und gleichzeitig sicherstellen, dass nur ein einziger Versuch zur Eingabe des korrekten Codes möglich ist.
Der Schlüssel liegt im PAKE
Um diesen Austausch mithilfe eines Codes abzusichern, verwenden wir ein symmetrisches Password Authenticated Key Exchange (PAKE) namens CPace. Möglicherweise sind Sie bereits mit dem Konzept eines PAKE vertraut, wenn Sie schon einmal von SRP (Secure Remote Password) gehört haben.
SRP ist ein asymmetrisches PAKE – das bedeutet, dass nur eine Partei im Austausch, nämlich Sie, das Passwort kennt. CPace hingegen ist ein symmetrisches PAKE, was bedeutet, dass beide Teilnehmer ein gemeinsames Geheimnis teilen.
Im Prozess zur Einrichtung eines neuen Geräts ist der zufällig generierte Bestätigungscode genau dieses gemeinsame Geheimnis. Nachdem Sie ihn auf dem neuen Gerät eingegeben haben, ist er beiden Geräten bekannt.
CPace wurde speziell dafür entwickelt, einen sicheren Kommunikationskanal zwischen zwei Geräten aufzubauen. Zudem verfügt das Verfahren über einen Sicherheitsnachweis für Perfect Forward Secrecy – Sie müssen sich also nicht allein auf unser Wort verlassen, dass der Prozess sicher ist.
Auf Protokollebene verhindert CPace elegant mögliche Brute-Force-Angriffe auf den gemeinsamen Code, indem der Handshake in zwei klar getrennte Phasen aufgeteilt wird.
Wie wir CPace bei der Geräte-Registrierung einsetzen
In der ersten Phase des Handshakes verwenden beide Geräte einen zufällig generierten Schlüssel sowie den gemeinsamen Code, um einen sogenannten „Commitment-Wert“ zu erzeugen. Da beide Seiten zusätzlich einen zufälligen Schlüssel einbringen, kann aus diesem Commitment nicht auf den eigentlichen Code geschlossen werden — es gibt schlicht zu viele unbekannte Faktoren.
Anschließend nutzen beide Geräte ihren jeweiligen Schlüssel sowie den gemeinsamen Code, um einen neuen gemeinsamen Schlüssel abzuleiten. Hatten beide Geräte von Beginn an denselben Code, gelangen sie zum selben gemeinsamen Schlüssel. Falls dies nicht der Fall ist — oder die Commitment-Werte manipuliert wurden — entstehen unterschiedliche Schlüssel.
Da dieser Schlüssel an den gemeinsamen Code, den Zustand des Handshakes sowie die zufällig generierten Schlüssel beider Seiten gebunden ist, kann der Code nicht erneut erraten werden, ohne den gesamten Austauschprozess von vorn zu beginnen.
Im nächsten Schritt folgt die zweite Phase von CPace: die Schlüsselbestätigung. Jede Seite verwendet ihre Version des gemeinsamen Schlüssels, um eine eindeutige Nachricht zu authentifizieren, die sie gegenüber der anderen Seite identifiziert.
Die Geräte senden unterschiedliche Bestätigungsnachrichten aneinander, können jedoch — sofern sie denselben Schlüssel besitzen — die Nachricht der jeweils anderen Seite verifizieren.
Sind diese Authentifizierungsnachrichten korrekt, wissen beide Geräte, dass der jeweils andere den richtigen Code verwendet hat. Ist dies nicht der Fall, wird der Vorgang abgebrochen.
Nach erfolgreicher Authentifizierung ist der Austausch abgeschlossen und die Geräte können über eine Ende-zu-Ende-verschlüsselte Verbindung kommunizieren.
Im letzten Schritt der Geräte-Registrierung verschlüsselt das bereits vertrauenswürdige Gerät das Credential Bundle mit dem gemeinsam abgeleiteten Schlüssel und überträgt es an das neue Gerät. Sobald das neue Gerät dieses erhält, kann es sich bei 1Password anmelden, die Daten entschlüsseln und sich selbst als vertrauenswürdiges Gerät registrieren, indem es einen eigenen Device Key generiert.
Verwaltung und Risiken
Die Möglichkeit, 1Password mit SSO-Anbietern zu integrieren, ist seit Langem ein häufig geäußerter Wunsch — aus gutem Grund. Single Sign-On spielt eine zentrale Rolle in der Unternehmenssicherheit: Es ermöglicht die Durchsetzung starker Authentifizierung, eine zentrale Verwaltung von Nutzer-Zugriffen sowie eine detaillierte Nachvollziehbarkeit von Anmeldeereignissen.
Allerdings bringt jedes SSO-System auch Sicherheits-Abwägungen mit sich. Sobald jemand einen gültigen Autorisierungs-Nachweis vorlegen kann — beispielsweise ein OAuth-Token oder eine SAML-Assertion — gewährt ein Dienst Zugriff auf die entsprechenden Daten. Die Informationen, die für diese Autorisierung erforderlich sind, werden häufig auf den Endgeräten der Nutzer gespeichert.
Die Funktion „Anmeldung mit SSO“ in 1Password löst dieses grundlegende Problem nicht: Gelingt es einem Angreifer, Zugriff auf den Computer eines Nutzers (oder auf eine Kopie der dort gespeicherten Daten) zu erhalten, kann er den Device Key sowie bestehende SSO-Sitzungen stehlen. Dadurch wäre es möglich, sich anzumelden und auf das 1Password-Konto mit aktiviertem SSO zuzugreifen.
Der Vorfall-Bericht zur jüngsten Sicherheitsverletzung bei CircleCI zeigt, dass das Entwenden lokal gespeicherter Zugangsdaten ein reales Risiko darstellt — selbst wenn starke Authentifizierungsmechanismen eingesetzt werden.
Der Schutz von SSO-Anmeldungen hängt daher maßgeblich von einem robusten Gerätesicherheits-Konzept sowie kontinuierlichem Security-Monitoring ab.
Für Leser mit Erfahrung im Bereich SSO mag diese Einschränkung offensichtlich sein und wird in der Praxis häufig durch ergänzende Sicherheitsmaßnahmen kompensiert. Viele werden zudem argumentieren, dass Autorisierungsmechanismen ein grundlegender Bestandteil von SSO-Systemen sind — und dass diese Systeme genau so funktionieren sollen.
Für unser Produkt war dieses Terrain jedoch neu und erforderte intensive konzeptionelle Überlegungen. Wir haben geprüft, inwieweit Identity Provider in der Lage sind, solche Missbrauchs-Szenarien zu erkennen oder zu verhindern — können jedoch keine Aussage über die tatsächlichen Fähigkeiten von Okta oder anderen Anbietern in diesem Zusammenhang treffen.
Auf Geräten, die die sichere Speicherung von Entschlüsselungs-Schlüsseln in Hardware unterstützen - etwa macOS, iOS oder Android -, schützen die 1Password-Apps den Device Key, sofern möglich, durch Hardware-basierte Sicherheitsmechanismen. Dadurch wird es deutlich schwieriger, diesen Schlüssel von einem Gerät zu extrahieren.
Grundsätzlich gilt: Der Schutz von SSO-Anmeldungen erfordert ein starkes Gerätesicherheits-Programm und kontinuierliche Überwachung.
Weitere sicherheitsrelevante Aspekte sollten Unternehmen vor der Einführung von SSO berücksichtigen — etwa die Sensibilisierung von Nutzern im Umgang mit Geräte-Einrichtungscodes sowie die Verfügbarkeit des Identity Providers für den Zugriff auf Passwörter. Weitere Informationen finden Sie in unserem Support-Artikel zur Sicherheit von SSO-Anmeldungen in 1Password.
Wie geht es weiter?
In diesem technischen Deep Dive ist Ihnen vielleicht aufgefallen, dass wir Okta nur selten direkt erwähnt haben. Da SSO-Anbieter (einschließlich Okta) in der Regel auf offenen Standards basieren, haben wir die Funktion Anmeldung über SSO mit Okta so entwickelt, dass sie künftig problemlos erweitert werden kann.
Die Unterstützung für Okta wird in Kürze allen 1Password-Business-Kunden zur Verfügung stehen. Anschließend werden wir uns auf Azure konzentrieren, gefolgt von weiteren Identity Providern wie Duo, OneLogin und anderen. Unsere ersten Releases werden sich vor allem auf OIDC fokussieren, SAML steht jedoch ebenfalls auf unserer Roadmap.
Ein weiterer Punkt, der technisch Interessierten auffallen könnte: Wird bei der Nutzung des Credential Bundles weiterhin Secure Remote Password (SRP) verwendet? Die Antwort lautet: Ja.
Aktuell ist es für uns sinnvoller, auf bestehende Entsperr-Mechanismen — einschließlich SRP — aufzubauen. Dadurch konnten wir die Anmeldung über SSO implementieren, ohne grundlegende Annahmen darüber zu ändern, wie Autorisierung innerhalb des 1Password-Dienstes funktioniert.
Gleichzeitig setzen wir SRP auch dann ein, wenn keine klassischen Kontopasswörter mehr verwendet werden. Falls Sie ein Passwort bei Ihrem Identity Provider nutzen, betrifft das ausschließlich die Beziehung zwischen Ihnen und diesem Anbieter.
Langfristig prüfen wir zudem die Möglichkeit, ein speziell entwickeltes System einzusetzen, über das ein 1Password-Gerät mit den 1Password-Servern kommuniziert, wenn die Authentifizierung über SSO erfolgt.
Während wir die Funktion für weitere Kunden mit unterschiedlichen Sicherheitsanforderungen ausbauen, arbeiten wir außerdem daran, noch feinere Kontrollmöglichkeiten für SSO-Anmeldungen bereitzustellen — einschließlich zusätzlicher Mechanismen zum Schutz des Geräteschlüssels.
Benutzerfreundliche Sicherheit für Unternehmen
Wir haben die Anmeldung über Single Sign-On so entwickelt, dass sie das zentrale Versprechen von 1Password erfüllt: Ihre Secrets gehören Ihnen – und nur Ihnen.
Der Geräteschlüssel sorgt dafür, dass sensible Daten ausschließlich lokal auf Ihrem Gerät verarbeitet werden. Durch den Einsatz von CPace lassen sich neue Geräte zudem schnell, einfach und sicher hinzufügen.
Für uns stehen Benutzerfreundlichkeit und Sicherheit nicht im Widerspruch. Im Gegenteil: Eine intuitive Nutzung ist selbst ein wichtiger Bestandteil moderner Sicherheitskonzepte – und genau das gilt auch für die Anmeldung über SSO.
Unser Ziel ist es, noch mehr Organisationen die Vorteile eines Enterprise Password Managers zugänglich zu machen, indem starke Sicherheitsmechanismen möglichst einfach nutzbar werden – auch wenn die zugrunde liegende Infrastruktur, wie wir gesehen haben, technisch komplex sein kann. 😉
Wenn Sie tiefer in die Funktionsweise der SSO-Anmeldung einsteigen möchten, finden Sie weitere Details im entsprechenden Abschnitt unseres Security-Design-Whitepapers.