Die Verwendung von Passwörtern hat eine lange Tradition in der IT. Und regelmäßig sind sich alle einig, dass wir sie eigentlich loswerden sollten. Das haben wir noch immer nicht geschafft, auch wenn Passkeys ein interessanter Ansatz sind. Daher sitzen wir alle auf großen Sammlungen von Passwörtern – die ca. 250 Einträge in meinem PW-Safe sind hoffentlich nicht repräsentativ – und im Internet tauchen in regelmäßigen Abständen immer absurd größere Passwort-Dumps auf. Es mehren sich auch Meldungen zu Datenlecks (aktuell PayPal), wo nicht klar ist, wo die Daten eigentlich abgeflossen sind. Solche Gerüchte können jede Organisation treffen, daher macht es Sinn, sich das Thema Passwörter in Ruhe anzuschauen.

Grundlagen

Dieser Blogpost schneidet das Thema nur kurz an, eine umfassende Behandlung des Themas Access Control liefert NIST SP800-63, in SP800-63B geht es im Detail um Passwörter. (Nebenbemerkung: die aktuelle Version enthält jetzt „Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.“)

Methoden zu Zugangskontrollen werden oft in drei Kategorien eingeteilt:

• Das, was ich bin: Biometrie, Stimme, Aussehen
• Das, was ich habe: Schlüssel, Token, Dienstausweis, Handy
• Das, was ich weiß: Username + Passwort, PIN

Eine Passwortabfrage ist einfach zu implementieren (und daher auch eine beliebte Aufgabe für Schüler): das eingegebene Passwort wir mit dem gespeicherten verglichen und so wird entschieden, ob der Zugang gewährt wird. Allzu simple sollte man das aber doch nicht machen, weil man folgendes berücksichtigen sollte:

• Die Übertragung von Passwörtern im Klartext ist gefährlich. Damals, im Zeitalter von offenen WLANs und vor dem breiten Einsatz von https war es ein beliebter Sport bei Konferenzen und Kaffeehäusern, die Passwörter anderer Leute aus dem Äther zu fischen.
• Ein Challenge-Response Verfahren statt eines simplen Vergleiches vermeidet das Passwort im Klartext, das hat sich aber bei Webanwendungen nicht durchgesetzt.
• Transport Layer Security (TLS) ist der übliche Weg, um neugierige Mithörer auszusperren.
• Serverseitig sollten Passwörter nicht im Klartext gespeichert werden, sondern als nur als (gesalzener) Hash. Die Verifikation ist weiterhin leicht möglich (Salz aus der DB nehmen, eingegebenes Passwort neu hashen, dann Ergebnis vergleichen. Mit einem dafür entwickeltem Hash-Verfahren kann man gut verhindern, dass Auslesen der Datenbank am Server nicht gleich alle Passwörter preisgibt
• Ist das Passwort aber zu einfach gewählt (geringe Komplexität oder häufiges Passwort in früheren Breaches), dann kann ein rohes Durchprobieren erfolgreich sein. Daher machen Vorgaben dazu (etwa eine Mindestlänge) und ein Check gegen Datenbanken bekannter Passwörter viel Sinn.
• Serverseitig sollte dieses Passwortraten erkannt und unterbunden werden – aber ohne das Ganze zum Denial-Of-Service Angriff gegen den legitimen Benutzer werden zu lassen.
• Optimal wären auch halbwegs zufällig Usernamen, in der Praxis werden bei den meisten Webseiten die Mailadressen der Nutzer als deren Username verwendet. Das erhöht die Wahrscheinlichkeit für erfolgreiche Credential-Stuffing Angriffe deutlich.

Wo gehen Passwörter verloren?

In der Praxis sind heute zwei Quellen für Passwort-Leaks relevant:

Serverseitig

Der Klassiker ist hier eine Schwachstelle in der Web-Applikation, die entweder direkt SQL Injection – und damit das Auslesen von Datenbanken – erlaubt, oder aber die Installation einer Webshell, was das Ausführen von beliebigem Code am Webserver ermöglicht. Natürlich ist auch ein anderer Weg als Einbruch in die Systeme denkbar, oder ganz etwas anderes wie unsachgemäße Entsorgung von alten Medien, Verlust von Laptops mit Kopien, böswilliges Handeln von Mitarbeitern oder Dienstleistern und was sonst noch alles die ISO 27k Norm im Risikokatalog dazu hat. Auch Einbrüche in veraltete Systeme, die eigentlich gar nicht mehr in Betrieb sind, aber trotzdem noch online waren, kamen schon mehrmals vor.

All das ermöglicht es Angreifern, die serverseitig zu Usern vorliegenden Daten komplett auszulesen. Solche Leaks haben meist folgende Eigenschaften:

• Die Daten sind schön strukturiert und sauber.
• Das Passwort ist hoffentlich nicht im Klartext enthalten – oft werden im Nachgang die einfach zu knackenden Hashes aufgelöst.
• Es gehen die Informationen zu allen Benutzern in gleichem Maße verloren.

Daten aus diesen Lecks werden im Darknet oft zum Kauf angeboten, nach einer Zeit landen sie dann auf Plattformen wie DeHashed oder HIBP. Verkäufer teilen oft auch kleine Ausschnitte der gesamten Datenbasis, um prospektive Käufer anzulocken.

Clientseitig

Aber auch auf der Seite des Nutzers kann das Problem sein, etwa weil Malware a) gespeicherte Passwörter aus dem Browser ausliest, b) oder sie als Keylogger Passwörter bei ihrer Eingabe speichert, c) eine trojanisierte Browsererweiterung Zugangsdaten abfängt oder d), weil der webbasierte Passwort-Safe ein Sicherheitsproblem hat. Aber nicht nur technische Angriffe bedrohen die Seite des Nutzers: Auch Social Engineering Angriffe wie etwa Phishing Webseiten oder E-Mails können dazu führen, dass Zugangsdaten in falsche Hände geraten.

Auch die auf diese Weise gestohlenen Zugangsdaten werden oft in kriminellen Untergrundforen getauscht oder verkauft. Sie zeichnen sich aus durch:

• Sie enthalten neben Username/Passwort auch oft die URL, zu der sie gespeichert wurden.
• Das Passwort ist im Klartext enthalten.
• Es trifft oft die Passwort-Sammlung eines Benutzers (viele verschiedene Webseiten), von einem Webshop sind aber nur einzelne User betroffen.
• Die Daten – insb. von Keyloggern – sind nicht sehr sauber.

Mischformen

Bei Kreditkarten-Skimming gab es auch Fälle, wo der Einbrecher am Server die dort vorliegenden Daten gar nicht ausgelesen hat, sondern nur ein kleines Stück JavaScript in die Webseite eingebaut hat, dass bei der Eingabe der Zahlungsinformation im Browser des Users, diese client-seitig per Web-Request an einen Webserver unter der Kontrolle der Angreifer geschickt hat.

Was heißt das für mich als Organisation?

Frägt man CISOs nach ihren Albträumen, dann wird „Passwörter meiner Organisation sind im Web aufgetaucht!“ sicher oft genannt. Aber was kann hinter so einer Schlagzeile stecken?

Eigene Systeme

Der schlimmste Fall ist, wenn direkt auf dem eigenen Server die Userdatenbank einer Webanwendung ausgelesen wurde. Woran könnte man das erkennen?

• Die Tätergruppe probiert eine Erpressung: „Zahlt mir was, oder ich veröffentliche die Daten!“
• In den Untergrundforen taucht der Leak explizit mit Nennung der Quelle auf. „example.com – complete userdb incl. passwords“
• Es trifft nicht nur einzelne meiner User, sondern alle.
• Die Datenbasis ist zeitlich konsistent: es sollte nicht sein, dass längst gelöschte alte User neben brandneuen Accounts auftauchen.

Die Reaktion wird wohl umfassend sein:

• Incident Response, um die Ursache zu ermitteln, zu beheben und sicherstellen, dass das Problem wirklich behoben ist - und sich auch nicht auswachsen könnte.
• Meldepflichten: Datenschutz, NIS und potenziell sektorspezifische Regulierungen.
• Information der Nutzer, Passwort-Änderungen.
• Analyse, wie man das ganze Setup besser machen könnte.

Fremde Systeme

Das ist leider fast Tagesgeschäft. Auch wenn man Privatnutzung der dienstlichen E-Mailadresse untersagt hat, so werden auch bei rein beruflicher Nutzung die Adressen der eigenen Mitarbeiter in diversen Kundendatenbanken landen. Das kann eine Konferenzanmeldung sein, eine Fluglinie, ein Hotel, ein Catering-Service, ein Lieferant, ein Kunde, ein soziales Netzwerk (ja, es gibt genug Jobs, wo das zur Arbeitsplatzbeschreibung gehört), eine Kammer oder eine staatliche Stelle, bei der sich Mitarbeiter registrieren müssen.

Die meisten davon werden hoffentlich ihre Systeme im Griff haben, aber rein statistisch gesehen wird es immer wieder vorkommen, dass eine dieser Datenbanken Beine bekommt und im Dark Web auftaucht.

Sucht irgendwer nach der Domain einer Organisation in den Untergrundforen oder den legitimen Leak Sammlungen, so tauchen dann die E-Mail-Adressen aller betroffener Mitarbeiter auf. Das allein kann schon für reißerische Schlagzeilen sorgen.

Haben diese Mitarbeiter etwas falsch gemacht? Nicht notwendigerweise.

Besteht eine Gefahr für die Organisation? Typischerweise bemerkt die Quelle des Leaks relativ bald den Vorfall und mitigiert das Problem auf ihrer Seite. Die große Gefahr hier ist die mehrfache Verwendung von Passwörtern. Beispiel: max.mustermann@example.com taucht im Leak einer Konferenzwebseite auf, und hat das gleiche Passwort auch für seinen Account bei einem Social Network benutzt. Ein Käufer des Leaks probiert die Adresse/Passwort Paare bei verschiedenen populären Webseiten durch kann so in einen Account einsteigen und Unfug treiben.

Die üblichen Empfehlungen für diesen Bereich sind:

• Die Nutzung der beruflichen E-Mail-Adresse für private Zwecke sollte nicht gestattet sein.
• Klare Vorgaben, dass Passwörter nicht doppelt verwendet werden.
• Dazu ist es nötig, dass Mitarbeitern entsprechende Werkzeuge (Passwortsafes) zur Verfügung gestellt werden.
• Aktivierung von 2-Faktor Authentication auf möglichst allen externen Systemen.
• Ein Zugriff von außen auf eigene Systeme muss durchgängig einen 2. Faktor verlangen.

Es kann sinnvoll sein, über Dienstleister das Auftauchen von eigenen Mailadressen in Untergrundforen und Leak-Seiten beobachten zu lassen, um möglichst proaktiv reagieren zu können.

Clientprobleme bei fremden Usern

Biete ich als Organisation eine Loginmöglichkeit für Kunden, Geschäftspartner oder Bürger an, so muss man leider davon ausgehen, dass diese ihre eigenen Systeme nicht zu 100% sicher betreiben und dass daher ein kleiner Teil davon ihre Zugangsdaten verlieren.

Je nach Applikation kann das harmlos oder gefährlich sein. Ein klassisches Beispiel ist das Online-Banking: hier haben Banken schon lange gelernt (und haben inzwischen auch harte staatliche Vorgaben), dass eine einfache Username/Passwort Kombination viel zu wenig Sicherheit bietet, um Geldgeschäfte abzuwickeln. Daher wurden hier schon früh TANs (Transaktionsnummern) eingeführt: zuerst auf Papier, dann SMS und jetzt über Apps.

Andersrum: wenn die Userdatenbank nur die Anmeldung zu einem Newsletter enthält, dann ist eine starke Absicherung schlicht unnötig, weil der mögliche Schaden nahe Null ist.

Aber eine PR-Tretmine ist das ganze allemal: Wenn ein Service eine signifikante Zahl an Nutzern hat, dann wird eine entsprechende Suche im Dark Web genug Treffer ergeben (jetzt in der URL-Spalte, und nicht mehr in der E-Mail-Spalte). Das kann bei genug Unwissenheit (oder Böswilligkeit) auch schon zu einem Skandal aufgeblasen werden.

Was kann man hier empfehlen?

• Als erstes muss man sich klar werden, wie heikel die Daten überhaupt sind, die über diesen Account angesprochen werden. Welcher Level an Zugangsschutz ist nötig?
• Kann die Authentifizierung outgesourced werden? Ein Passwort, das gar nicht vorhanden ist, kann nicht gestohlen werden.
  • Für harmlose Services kann man das etwa über „Login via Google/Apple/Github/…“ oder eine simple E-Mail-Schleife lösen.
  • Für heiklere Dienste bietet sich eine Anbindung an ID-Austria an.
• Auch hier können Dienstleister, die das Dark Net zu Passwort Leaks beobachten, helfen, proaktiv zu agieren, statt im Nachhinein auf Presseanfragen reagieren zu müssen.

Clientprobleme bei eigenen Mitarbeitern

Wie man die Endgeräte seiner Mitarbeiter absichert, ist ein hartes Problem und soll hier nicht behandelt werden. Auch das Thema "Wie schule ich meine Mitarbeiter in der Erkennung von Social Engineering?" ist nicht trivial, wie ein aktuelle Studie belegt.

Zwei Empfehlungen von oben gelten hier jedenfalls auch:

• Man muss davon ausgehen, dass Mitarbeiter Passwörter verlieren und die Sicherheitsarchitektur der eigenen IT entsprechend anlegen.
• Ein Monitoring von Untergrundforen kann auch hier Sinn machen.

Zusammenfassung

Nicht alle „Password-Leaks“ sind gleich, und nicht für alle ist man selbst verantwortlich.

Zur eigenen Verantwortung zählt:

• Sich der Gefahr (und sei es nur PR-Drama) bewusst sein
• Fehler im eigenen Bereich so gut wie möglich ausschließen
  • Datensparendes Arbeiten kann hier hilfreich sein
• Die eigene Reaktion auf Fehler Dritter vorbereiten
• Dafür sorgen, dass man nicht überrascht wird