Die NIS2-Richtlinie ist der aktualisierte Cybersicherheitsrahmen der Europäischen Union, der die Cyberresilienz in kritischen Sektoren verbessern soll. Aufbauend auf der Richtlinie seines Vorgängers, der Richtlinie über
Passwortmanager gehören zu den hilfreichsten Sicherheitstools auf dem Markt und bieten eine starke Passwortgenerierung und die Speicherung verschlüsselter Zugangsdaten. Allerdings nehmen Angreifer mittlerweile zunehmend Passwortmanager ins Visier, indem sie den Geräteregistrierungsprozess ausnutzen, also den Vorgang, mit dem ein neues Gerät überprüft und genehmigt wird, bevor es auf den Tresor eines Benutzers zugreifen kann. Durch Brute-Force-Angriffe auf die Einmalpasswörter (OTPs), die diesen Schritt schützen, können Angreifer nicht autorisierte Geräte registrieren und Kopien verschlüsselter Tresore herunterladen.
Genau das ist Dashlane im Mai 2026 passiert: Angreifer haben die sechsstelligen Codes, die zur Registrierung neuer Geräte verwendet werden, mit Brute-Force-Angriffen geknackt, unbefugte Geräte zu weniger als 20 Konten hinzugefügt und Kopien der Tresore dieser Benutzer heruntergeladen. Die Verschlüsselung selbst wurde nie geknackt, doch die Schwachstelle lag in der Art der Genehmigung neuer Geräte. Die auf die Registrierung von Passwortmanager-Geräten abzielenden Brute-Force-Angriffe stellen eine wachsende Cyberbedrohung dar, sind jedoch unwirksam gegen die Zero-Trust- und Zero-Knowledge-Architektur von Keeper, die sicherstellt, dass die Kenntnis eines Passworts nie ausreicht, um ein Gerät zu registrieren und auf einen Tresor zuzugreifen.
So funktionieren Brute-Force-Angriffe auf die Geräteregistrierung
Wenn Sie ein neues Gerät zu einem Passwortmanager hinzufügen, muss der Dienstanbieter überprüfen, ob das Gerät Ihnen gehört, bevor er Ihnen Zugriff auf Ihren Tresor gewährt. Dieser Bestätigungsschritt beim Geräteregistrierungsprozess ist das Ziel dieser Brute-Force-Angriffe. Um zu verstehen, warum Passwortmanager wie Dashlane für diesen Angriff anfällig waren, während andere wie Keeper® nicht betroffen waren, sehen wir uns zunächst einmal den typischen Ablauf solcher Angriffe an:
- Ein Code wird ausgegeben: Nachdem ein neues Gerät zu einem Konto hinzugefügt wurde, muss der Dienst die Identität des Benutzers in der Regel durch das Versenden eines sechsstelligen OTP-Codes per E-Mail oder durch Generierung mit einer Authentifikator-App überprüfen. Die Eingabe dieses Codes beweist, dass die registrierte Person der legitime Kontoinhaber ist.
- Der Endpunkt wird mit Anfragen überflutet: Da ein sechsstelliger OTP-Code nur 1 Million mögliche Kombinationen hat, kann ein Angreifer einen API-Endpunkt für die Geräteregistrierung mit automatisierten Anfragen überfluten. Wenn der Endpunkt keine Ratenbegrenzungen, Ablaufzeiten für Codes oder Sperren nach bestimmten Versuchsanzahlen durchsetzt, kann der Angreifer mögliche Werte rasch ausprobieren, bis er den gültigen Code ermittelt hat.
- Ein gültiger Code wird erraten: Nach einer ausreichenden Anzahl von Versuchen bei einem schlecht geschützten Endpunkt wird der Angreifer früher oder später den richtigen Code erraten. Da dieser Code als Nachweis für die Identität des Benutzers dient, wird das Gerät des Angreifers als legitim akzeptiert.
- Das Gerät ist registriert: Der Dienstanbieter autorisiert das neue Gerät und synchronisiert den verschlüsselten Tresor des Benutzers damit. Obwohl die Tresordaten weiterhin verschlüsselt sind, verfügt der Angreifer nun über eine Kopie der verschlüsselten Daten und kann versuchen, diese offline beliebig lange zu entschlüsseln.
Dieser Vorgang ist keine hypothetische Annahme; genau so hat sich der Angriff auf Dashlane abgespielt. Deshalb ist die Sicherung des Geräteregistrierungsprozesses genauso wichtig wie der Schutz von Tresoren.
Warum eine unautorisierte Geräteregistrierung ein Risiko darstellt
Die Registrierung unbefugter Geräte birgt ernsthafte Sicherheitsrisiken, denn sobald ein neues Gerät für ein Passwortmanager-Konto registriert ist, kann es auf den Tresor des Benutzers zugreifen und als authentifizierter, legitimer Benutzer erscheinen. Der Angreifer muss zur Durchführung dieser Art von Brute-Force-Angriff die Verschlüsselung des Tresors weder umgehen, schwächen noch knacken. Es reicht aus, wenn der Dienstanbieter seinem Gerät vertraut, sodass die verschlüsselten Tresordaten direkt auf die Hardware synchronisiert werden können, die unter seiner Kontrolle steht.
Die Folgen einer Kopie des verschlüsselten Tresors eines Benutzers in den Händen eines Angreifers sind langfristig, da der Angreifer versuchen kann, diesen offline in seinem eigenen Tempo zu knacken – so lange, bis er Zugriff erlangt. Auch wenn eine starke Verschlüsselung des Tresors den Erfolg statistisch gesehen unwahrscheinlich macht, hängt die Erfolgswahrscheinlichkeit doch maßgeblich von einem Faktor ab, den der Benutzer selbst beeinflussen kann: der Stärke seines Master-Passworts. Ein langes, komplexes und einzigartiges Master-Passwort kann verhindern, dass ein gestohlener Tresor geknackt wird, wohingegen ein schwaches oder wiederverwendetes Master-Passwort mit ausreichend Zeit mit einer deutlich höheren Wahrscheinlichkeit geknackt wird. Die Sicherung des Geräteregistrierungsprozesses ist unerlässlich, damit der Schutz des Tresors eines Benutzers nicht ausschließlich von der Stärke seines Master-Passworts abhängt.
So verhindert Keeper Brute-Force-Angriffe im Rahmen der Geräteregistrierung
Nutzer von Keeper würden nicht Opfer derselben Art von Brute-Force-Angriff werden, von dem Dashlane betroffen war, da Keeper sicherstellt, dass es nicht ausreicht, lediglich das Passwort eines Nutzers zu kennen oder ein OTP per Brute-Force zu knacken, um ein neues Gerät zu registrieren oder auf einen Tresor zuzugreifen.
Gerätegenehmigung
Bei Keeper muss jedes neue Gerät ausdrücklich genehmigt werden, bevor es auf einen Tresor zugreifen kann. Diese Genehmigung ist ein separater, bewusster Schritt und erfolgt nicht automatisch, sobald ein Code eingegeben wird. Bei einzelnen Benutzern erfolgt die Genehmigung durch den Kontoinhaber über ein bereits vertrauenswürdiges Gerät; in Unternehmen kann ein Administrator neue Geräte im Namen berechtigter Benutzer genehmigen. Bei dieser Art von Angriff reicht es aus, ein gültiges Einmalpasswort (OTP) zu erraten, um die Geräteregistrierung abzuschließen. Bei Keeper hingegen gibt es keinen einzelnen API-Endpunkt, dessen Code durch Brute-Force-Angriffe erraten werden kann, um den Prozess abzuschließen.
Multi-Faktor-Authentifizierung (MFA)
Keeper unterstützt eine Vielzahl von Methoden für MFA bzw. 2FA (Zwei-Faktor-Authentifizierung), darunter FIDO2/WebAuthn-Hardware-Sicherheitsschlüssel, die biometrische Authentifizierung, Authentifizierungs-Apps und SMS. Nicht alle diese Methoden sind jedoch gleichermaßen gegen Brute-Force-Angriffe wirksam. Per E-Mail oder SMS versendete Codes sind am anfälligsten, da sie erraten oder während der Übertragung abgefangen werden können. Authentifizierungs-Apps bieten einen besseren Schutz, da der Code lokal auf dem Gerät des Benutzers generiert wird. Dennoch basieren sie auf kurzen, zeitabhängigen Codes und sind daher zur Verhinderung von Brute-Force-Angriffen auf Ratenbegrenzungen und andere Kontrollmaßnahmen angewiesen. Hardware-Sicherheitsschlüssel bieten den besten Schutz, da sie auf einer kryptografischen Challenge-Response-Authentifizierung und nicht auf einem kurzen Code basieren. Da es keinen vorhersehbaren Wert gibt, den ein Angreifer wiederholt an einen API-Endpunkt senden könnte, sind auf die Geräteregistrierung abzielende Brute-Force-Angriffe wirkungslos.
Zero-Trust-Sicherheit
Keeper basiert auf einem Zero-Trust-Sicherheitsmodell, d. h., jede Zugriffsanfrage muss unabhängig vom Netzwerkstandort oder früheren Authentifizierungsvorgängen überprüft werden. Bei Keeper wird einem Gerät nicht allein aufgrund der bereits erfolgten Registrierung oder Verifizierung dauerhaftes, implizites Vertrauen gewährt. Jede Anfrage wird unabhängig geprüft. Bei diesem Sicherheitsmodell würde selbst dann, wenn es einem Angreifer irgendwie gelänge, ein Gerät zu registrieren, dieser einmalige Erfolg keinen dauerhaften Zugriff gewähren. Bei einem Zero-Trust-Framework gibt es keinen Mechanismus, über den ein Angreifer die Geräteregistrierung zur Erlangung unbefristeter Zugriffe ausnutzen könnte.
Modul für erweiterte Berichte und Warnungen (ARAM)
Das Modul für erweiterte Berichte und Warnungen (ARAM) von Keeper bietet Administratoren einen Überblick über verdächtige Aktivitäten in ihrer gesamten Umgebung, einschließlich Anomalien bei der Authentifizierung und Versuchen zur Geräteregistrierung. Verifizierungsversuche, die innerhalb eines kurzen Zeitraums erfolgen, oder eine hohe Anzahl fehlgeschlagener Versuche zur Geräteregistrierung sind genau die Art von Ereignissen, die ARAM aufdecken kann. Durch den vollständigen Überblick über ungewöhnliche Aktivitäten können Administratoren schnell reagieren, anstatt verdächtiges Verhalten erst dann zu bemerken, wenn ein nicht autorisiertes Gerät bereits registriert wurde.
Um mehr darüber zu erfahren, wie die Gerätegenehmigungs-, Authentifizierungs- und Verschlüsselungsarchitektur von Keeper im Vergleich zu der von Dashlane abschneidet, besuchen Sie unsere Vergleichsseite Keeper vs. Dashlane.
Warum die Zero-Knowledge-Architektur von Keeper wichtig ist
Die Zugriffskontrollen von Keeper sind darauf ausgelegt, Angreifer daran zu hindern, ein Gerät überhaupt zu registrieren, doch eine weitere Schutzebene verbessert die Sicherheit noch zusätzlich: eine Zero-Knowledge-Architektur. In der Praxis bedeutet Zero-Knowledge, dass alle im Tresor eines Benutzers gespeicherten Daten jederzeit durchgehend verschlüsselt sind, sodass nicht einmal Keeper sie entschlüsseln kann. Da die Verschlüsselungsschlüssel auf dem Gerät des Benutzers generiert werden, werden die Daten ebenfalls lokal verschlüsselt und entschlüsselt, wodurch sichergestellt wird, dass der Tresor vollständig unter der Kontrolle des Benutzers bleibt. Selbst wenn ein Angreifer irgendwie Zugriff auf eine Kopie des verschlüsselten Tresors eines Benutzers erlangen sollte, stünde er vor einer nahezu unüberwindbaren Herausforderung, da die zum Entsperren eines Keeper-Tresors erforderlichen Verschlüsselungsschlüssel nicht in der Infrastruktur von Keeper gespeichert sind.
Schützen Sie mit Keeper Ihre Daten vor Brute-Force-Angriffen
Der Sicherheitsvorfall bei Dashlane beweist, dass eine starke Tresorverschlüsselung allein nicht ausreicht. Da Angreifer ihren Fokus zunehmend vom Knacken verschlüsselter Tresore auf die Ausnutzung der Zugriff gewährenden Workflows verlagern, ist es von entscheidender Bedeutung zu verstehen, wie Brute-Force-Angriffe verhindert und die Prozesse zur Geräteregistrierung und -authentifizierung gesichert werden können. Ein Passwortmanager muss sowohl die Benutzertresore als auch den Workflow schützen, der den Zugriff darauf regelt.
Die Datenschutzverletzung bei LastPass im Jahr 2022 hatte ein ähnliches Ergebnis, verlief dabei jedoch anders: Angreifer drangen in die Infrastruktur des Unternehmens ein und stahlen Kopien verschlüsselter Tresore, doch Sicherheitsexperten konnten den Diebstahl inzwischen auf unzureichend geschützte Tresore zurückführen. Die Vorfälle bei Dashlane und LastPass zeigen, dass ein verschlüsselter Tresor eines Benutzers dauerhaft angegriffen werden kann, sobald ein Angreifer Zugriff darauf erlangt hat. Daher ist es umso wichtiger, einen sicheren Passwortmanager zum Schutz Ihrer Daten zu verwenden.
Keeper wurde zur Abwehr solcher Angriffe entwickelt und nutzt dazu die Gerätegenehmigung, bei der sichergestellt wird, dass ein erratener Code nicht eigenständig ein neues Gerät registrieren kann, sowie mehrere MFA-Methoden und ein Zero-Trust-Sicherheitsmodell, das gewährleistet, dass keinem Gerät implizit vertraut wird. Diese Schutzmaßnahmen basieren auf einer Zero-Knowledge-Architektur, bei der die Verschlüsselungsschlüssel unter der Kontrolle des Benutzers bleiben.
Starten Sie eine kostenlose Testversion von Keeper, um zu erfahren, wie das mehrstufige Sicherheitskonzept gewährleistet, dass Ihre Tresordaten mit Schlüsseln verschlüsselt werden, über die nur Sie die Kontrolle haben.