Passwörter und insbesondere Passwort-Vorgaben sind ein spannendes Feld voller Konfliktpotential, gefährlichem Halbwissen und gefühlter Sicherheit. Neben Passwörtern an sich, ist auch das Thema Multi-Faktor-Authentifizierung ein naheliegender Diskussionspunkt. Zu beiden Themen möchten wir ein paar Einblicke und Empfehlungen aus Sicht eines Angreifers geben, die vielleicht beim nächsten Review der Passwort-Richtlinie behilflich sein können.
Wer A sagt, muss auch B sagen!
Anfang des Jahres hat das BSI seine Empfehlungen zu Passwörtern an einigen Stellen grundlegend geändert. Mit dem neuen Weg schließt sich das BSI anderen Vorreitern, wie dem NIST an. Kernpunkt vieler Diskussionen war die geänderte Vorgabe zur Häufigkeit von Passwortwechseln. Die Zusammenfassung lautete in den Medien oft etwa so: Das BSI empfiehlt, keine regelmäßigen Passwort-Wechsel mehr zu erzwingen. Die Aussage stimmt so grundsätzlich schon, ist jedoch mit einem dicken ABER verknüpft.
Wer
- den regelmäßigen Passwort-Wechsel abschafft, muss
- diverse andere Vorgaben erfüllen – die es technisch oft in sich haben!
Viel zu oft wird beim Thema Passworte dabei nur über eine Seite diskutiert.
Empfehlungen zur Passwortrichtlinie
Konkrete Empfehlungen sind nicht an allen Stellen für jeden Anwendungsfall gegeben. Erstaunlicherweise unterscheiden die meisten konkreten Vorgaben beispielsweise nicht zwischen Passwörtern für reguläre Benutzeraccounts und Passwörtern für privilegierte Benutzer. Hier ein paar Beispiele aus den Vorgaben verschiedener Institute und Organisationen:
[ninja_tables id=“8524″]
Es gibt je nach Standard noch weitere Empfehlungen, die aber für die hier vorgenommene Betrachtung nicht mehr relevant sind. Grundlegend sollten Passwörter natürlich immer geheim, sicher, schwer zu erraten und gut zu merken sein – Ha!
Angriffspunkte und Angriffswege
Online oder offline?
Wenn wir über den Schutz von Accounts durch Passwörter reden, sollten wir grundsätzlich zwischen zwei Welten von Angriffen unterscheiden. Die, bei denen direkt „online“ mit einem System interagiert wird und solche, bei denen ein Angreifer „offline“ im stillen Kämmerlein mit einem zuvor geklauten Passworthash arbeiten kann.
Beispiele für „online“-Angriffe sind hierbei:
- Angriffe auf die Windows-Anmeldung
- Angriffe auf Unternehmenswebseiten wie Office365
- Angriffe auf Banking-Webseiten
- Angriffe auf BitLocker-PINs
Beispiele für “offline”-Angriffe:
- Angriffe auf Passwort-Hashs
Brechstange oder Intelligent?
Wenn ein Einbrecher in Ihr Haus einbrechen möchte, gibt es eine mehrere mögliche Vorgehensweisen, beispielsweise:
- per Brechstange durch die Fensterscheibe,
- mit dem Lock-Picking-Set durch die Haustür oder
- mit dem Zweitschlüssel unter der Fußmatte.
So ähnlich verhält es sich auch mit Angriffen auf Authentifizierungsdienste bzw. Anwendungen. Mit brachialer Gewalt und Milliarden von Rateversuchen gehen klassische Brute-Force-Angriffe ans Werk. Hierbei wird einfach stupide jede Kombination von Zeichen im möglichen Zeichenraum durchprobiert. Ein bisschen mehr Hintergrundwissen verwenden sogenannte Credential-Stuffing-Angriffe, bei denen nur Passwörter durchprobiert werden, die bereits aus früheren Angriffen oder veröffentlichten Passwortdatenbanken als valide Passwörter bekannt sind. Das reduziert die Anzahl an Versuchen enorm, bringt aber auch nicht die theoretische Erfolgsquote von 100%, die ein klassischer Brute-Force-Angriff mit genügend Zeit vorweisen kann. Dazwischen liegen Wörterbuchangriffe. Hierbei werden gezielt Passwörter zusammengesetzt, die in der Regel zu großen Teilen in Wörterbüchern stehen. Dabei werden typische Muster, wie etwas Jahreszahlen oder Monatsziffern variiert, um eine größere Trefferquote als beim Credential Stuffing zu erlangen und dennoch deutlich weniger Rateversuche zu generieren, als bei klassischen Brute-Force-Angriffen. In den Bereich des „Intelligenten Raten“ von Passwörtern fallen auch Angriffe, die dynamische Wörterbücher zusammenbauen – etwa auf Basis der Webseite der Zielfirma oder den Informationen aus Social Media über eine Zielperson. Wer seinen Porsche911 liebt und bei Porsche arbeitet, der hat möglicherweise auch ein Passwort, was diese Liebe widerspiegelt. Im Detail gibt es noch mehr Variationen dieser Angriffe. Im Grund genommen läuft es aber auf die drei Szenarien heraus:
- Verwendung eines bereits bekannten / gebrochenen Kennworts
- Verwendung eines schlecht generierten bzw. schwachen, aber unbekannten Kennworts
- Verwendung eines beliebigen Passworts, mit zu kleinem Werteraum
Der Erfolg solcher Angriffe in Abhängigkeit der Empfehlungen für Passwortvorgaben muss in die Bereiche „online“-Angriffe und „offline“-Angriffe unterschieden werden, um die Auswirkungen der einzelnen Vorgaben in einen sinnvollen Kontext zu rücken.
Wertebereiche und Zahlenräume
Um die Empfehlungen, insbesondere mit Blick auf Länge und Komplexität im Kontext von online- und offline-Angriffen zu bewerten, brauchen wir zunächst ein paar konkrete Zahlen.
- Wir nehmen als Werteräume an:
- ein Alphabet von 26 Buchstaben, also 52 Möglichkeiten bei Groß / Kleinschreibung,
- 10 mögliche Ziffern,
- 25 verfügbare Sonderzeichen.
- Geburtstagsparadoxon und co. klammern wir aus.
Die zu knackenden Passwörter bestehen in den Szenarien aus:
- jeweils 8 Zeichen (Groß- / Kleinschreibung) [52^8 mögliche Werte]
+ inklusive Zahlen [62^8 mögliche Werte]
+ inklusive Zahlen und Sonderzeichen [87^8 mögliche Werte]
- jeweils 8 Zeichen (Groß- / Kleinschreibung) [52^8 mögliche Werte]
+ inklusive Zahlen [62^8 mögliche Werte]
+ inklusive Zahlen und Sonderzeichen [87^8 mögliche Werte] - jeweils 12 Zeichen (Groß- / Kleinschreibung) [52^12 mögliche Werte]
+ inklusive Zahlen [62^12 mögliche Werte]
+ inklusive Zahlen und Sonderzeichen [87^12 mögliche Werte] - jeweils 16 Zeichen (Groß- / Kleinschreibung) [52^16 mögliche Werte]
+ inklusive Zahlen [62^16 mögliche Werte]
+ inklusive Zahlen und Sonderzeichen [87^16 mögliche Werte]
Die Anzahl möglicher Werte für ein Passwort, die im Zweifel vollständig durchprobiert werden müssten, ergibt sich demnach aus der Berechnung der Komplexität und der Länge des Passworts. Zusammengefasst sieht das beispielsweise so aus.
Online-Angriffe
Beginnen wir mit den „online“-Angriffen. „online“-Angriffe sind dabei nicht nur als Angriffe auf Dienste oder Anwendungen im Internet zu verstehen. Online bezieht sich vielmehr darauf, dass der Angriff durch direkte Interaktion mit dem Zielobjekt stattfindet, also das angebotene Authentifizierungssystem verwendet wird, um Zugriff auf eine Anwendung oder einen Dienst zu erlangen. Dabei ist völlig egal, ob es sich dabei um einen Windows-Client, eine Anwendung im internen Netz oder die Authentifizierung der Azure-/Office365-Cloud handelt.
Charakteristisch für online-Angriffe ist demnach die Auffälligkeit im Logging und Monitoring des Anbieters, sowie die Abhängigkeit von den Vorgaben des Zielsystems und der Übertragungswege. Beispiel: Ein Angriff auf eine Webanwendung erfordert in der Regel mindestens einen POST-Request an das Zielsystem, welcher dort verarbeitet und beantwortet wird. Dabei können mehrere Anfragen parallel gestellt werden. Jede Anfrage hat bedingt durch den Übertragungsweg eine gewisse Verzögerung.
Ungebremste Angriffe auf Webanwendungen
Natürlich ist die tatsächliche Performance von Webanwendungen unfassbar unterschiedlich. Für die Veranschaulichung der Auswirkungen der Passwort-Regeln benötigen wir auch hier wieder ein paar Annahmen. Wir nehmen also an:
- Die Anwendung verarbeitet maximal 1000 Anfragen pro Sekunde
- Die Verarbeitungsdauer (inkl. Übertragung) pro Anfrage beträgt 1 Sekunde
- Der Login verfügt über keinerlei Gegenmaßnahmen
Ein klassischer Brute-Force-Angriff, der den gesamten Werteraum bei einem 8-stelligen Kennwort (Groß-/Kleinbuchstaben) von 53.459.728.531.456 möglichen Passwort-Kombinationen abdeckt und 1.000 Versuche pro Sekunde schafft, würde demnach etwa 14.849.924 Stunden bzw. 1.695 Jahre dauern. Dieser Ansatz macht für einen Angreifer also schon hier absolut keinen Sinn. Würde die Anwendung nur minimale Anti-Automatisierungsmaßnahmen implementieren, also beispielsweise von einer IP-Adresse pro Sekunde nur 10 Anfragen verarbeiten, dann würde sich die benötigte Zeit nochmals um den Faktor 100 vergrößern – selbst ohne Ziffern und Sonderzeichen.
Klassische Brute-Force-Angriffe auf Authentifizierungsdienste sind daher für einen Angreifer in der Regel unpraktikabel.
Anti-Automatisierung
Wozu also noch CAPTCHAs und Multi-Faktor-Authentifizierung? Naja, wegen der Benutzer, und deren Neigungen bei der Vergabe von Passwörtern: Die sind halt nicht immer zufällig gewählt und werden mitunter bei mehreren Diensten verwendet. Und hier setzen die aktuell häufig gesehenen Credential-Stuffing-Angriffe und Wörterbuch-Angriffe an. Listen der Top-1.000- bis Top 10.000-Passwörter gibt es im Internet zuhauf. Wenn ein Benutzer eines dieser Passwörter verwendet, dann beträgt die Dauer für einen Angriff unter obigen Annahmen nur 10 Sekunden – und ein Angreifer hat Zugriff auf den Account seines Opfers. Selbst zeitliche Verzögerungen um den Faktor 100 würden aus den 10 Sekunden hier nur eine Dauer von 1.000 Sekunden – also knapp 16 Minuten – machen, bis ein Angreifer das Konto kompromittiert hat. Das ist auf jeden Fall ein praktikabler Angriff. Die Länge und Komplexität des gewählten Passworts sind dabei weitestgehend vernachlässigbar: taucht das Kennwort in einer Liste der Top-Passwörter oder in der Liste von Passwörtern aus einem vorherigen Passwort-Breach auf, sind es in der Regel wenige zehntausend Versuche pro Account, die ein Angreifer für einen erfolgreichen Angriff benötigt.
Um vor solchen Angriffen zu schützen bieten beispielsweise CAPTCHAs oder andere Mechanismen die Möglichkeit, das automatisierte, massenhafte Durchraten von Benutzername-Passwort-Kombinationen zu vermeiden. Das hilft freilich nur, wenn der Angreifer sich nicht die Mühe macht, hier selbst Hand anzulegen. Ist ein Ziel spannend oder wertig genug, dann werden schon mal ein paar hundert Passwörter trotz CAPTCHA und co. über verteilte IP-Adressen und „menschliche Bots“ durchprobiert. Ist dann kein zusätzlicher Schutz implementiert, gerät der Account in fremde Hände.
Multi-Faktor-Authentifizierung
Einen zusätzlichen Schutz bieten in der Regel Multi-Faktor-Authentifizierungssysteme. Die Idee dahinter: ein Angreifer benötigt Benutzername + Passwort + einen zusätzlichen Token o.ä., um Zugriff auf den Account zu erlangen. MFA birgt in der Praxis an vielen Stellen das Risiko falscher Sicherheit. Viele Implementierungen – dazu gehören übrigens auch Azure / O365 und Amazon AWS – fragen den zusätzlichen Faktor nach einer erfolgreichen Anmeldung mit Benutzername und Passwort ab. Das bedeutet, der Angreifer weiß an dieser Stelle, dass das Kennwort zu diesem Benutzernamen gehört, er also eine gültige Zugangskennung besitzt. Zwar kommt er nicht an den aktuell angegriffenen und per MFA abgesicherten Dienst, aber mal an die eigene Nase gepackt: Sind wirklich alle Internet-erreichbaren Dienste mit MFA abgesichert? Und ist wirklich ausgeschlossen, dass ein Angreifer mit den AD-Credentials irgendwie on-Premises ins Netzwerk gelangt?
Eine Benachrichtigung über eine erfolgreiche Benutzername-Passwort-Authentifizierung und eine abgebrochene MFA-Authentifizierung bekommt man von den Diensten übrigens im Standard nicht, wenn man die Authenticator App mit Tokeneingabe verwendet. Die nachfolgende Grafik veranschaulicht dies am Beispiel von Azure:
Existiert das Konto nicht, so gibt Microsoft einem Angreifer diese Information preis (1) – was übrigens nicht den üblichen Empfehlungen für Logins entspricht. Ist der Benutzername korrekt, fragt Microsoft zuerst nach dem Passwort (2). Wird dies falsch „geraten“, so lehnt Microsoft den Login ab (3). Stimmt das Kennwort, dann kommt die Aufforderung zur MFA-Eingabe (4). An dieser Stelle weiß der Angreifer zumindest, dass er eine aktuell gültige Kombination aus Benutzername und Passwort besitzt, welche er an weiteren Diensten der Firma – oder ggf. vor Ort mal ausprobieren kann.
Offline-Angriffe
Bei „offline“-Angriffen kann der Angreifer in aller Ruhe auf die gespeicherten Passwort-Hashes losgehen. Hier zählt also nur noch die Widerstandsfähigkeit der gespeicherten Passwörter gegen – MFA und co. sind hier wirkungslos.
Grundvoraussetzungen für die sichere Speicherung von Passwörtern sind:
- die Verwendung eines geeigneten Hash-Verfahrens
- die Verwendung eines SALTS
Hash-Verfahren und co.
Hash-Verfahren gibt es viele, z. B.: MD4, MD5, SHA1, SHA, PBKDF2, BCRYPT. Für die Beurteilung der Widerstandsfähigkeit ist dabei insbesondere wichtig, dass die Verfahren zu grundlegend unterschiedlichen Zwecken erfunden wurden. MD5 etwa wurde dafür gedacht, möglichst effizient einen Hash-Wert von einer großen Datenmenge zu berechnen. Der Algorithmus ist auf Tempo ausgerichtet – eine Eigenschaft, die bei der Speicherung von Passwörtern ein Problem darstellt, da sie das Durchraten von Passwörtern beschleunigt.
Für Passwort-Hashes gibt es moderne Verfahren wie PBKDF2, welches gezielt so gestaltet wurde, dass die Berechnung eines Hashwertes zu einem Ausgangswert verhältnismäßig lange dauert.
Für die konkrete Geschwindigkeit gibt es verschiedene Messungen – je nach Hardware. Ein paar Beispielwerte für die Anzahl von Hashwerten, die mit identischer Hardware pro Sekunde berechnet werden können, sehen etwa so aus:
[ninja_tables id=“8552″]
Je nach Hardware und verwendeten Werkzeugen können diese Werte natürlich stark unterschiedlich ausfallen. Die Dimensionen bzw. das Verhältnis der Geschwindigkeit zur Berechnung von Hashwerten zwischen den einzelnen Verfahren bleibt aber immer etwa gleich.
Brechen von Hashwerten
Um ein wenig Aussagekraft zu haben, müssen wir auch hier ein paar Annahmen treffen. Nehmen wir also mal an:
- ein Angreifer kommt in den Besitz der Hashwerte UND der SALT-Werte
- ein Angreifer versucht per Holzhammer-Methode einen kompletten Brute-Force-Angriff
Mit den zuvor genannten Geschwindigkeiten können die Hash-Werte aller möglichen Eingabewerte wie folgt (in Minuten) berechnet werden:
[ninja_tables id=“8559″]
Plakativ gesagt bedeutet das, dass ein Passwort aus 8 Zeichen (Groß-/Kleinschreibung), was als MD5-Hash in einer Datenbank gespeichert wurde, innerhalb von 4 Minuten per Brute-Force-Angriff auf jeden Fall erraten werden kann. Bei PBKDF-gehashten Passwörtern der gleichen Komplexität, dauert ein solcher Angriff 11.033 Minuten, also etwa 183 Stunden – was knapp 7 ½ Tagen entspricht. Verlängern wir nur das Kennwort um 4 Zeichen und bleiben bei Groß-/Kleinschreibung, dauert ein Angriff auf ein MD5-gehashtes Passwort 32.573.084 Minuten, also etwa 542.884 Stunden – umgerechnet 22.610 Tage; Knapp 62 Jahre.
Wird statt der Länge nun die Komplexität hochgesetzt, ergibt sich zur Berechnung aller Hashes der Werteraums eines 8-Zeichen langen Passworts mit Zahlen eine Dauer von 18 Minuten, mit Zahlen und Sonderzeichen von 114 Minuten – also nicht mal zwei Stunden. In Windows-Umgebungen werden in der Regel die Hashverfahren NTLMv2 und MSCacheV2 verwendet. Das achtstellige Passwort eines lokalen Windows 10 Benutzers, was im NTLMv2-Format gespeichert ist, lässt sich demnach auch in einer guten Stunde berechnen – mit maximaler Komplexität dauert die Berechnung aller möglichen Werte immerhin knapp einen Tag.
Die Moral von der Geschicht‘: Hohe Komplexitätsanforderungen lohnen sich mit Blick auf Brute-Force-Angriffe gegen die Passwort-Hashs nicht! Der in diesem Zusammenhang oft gelesene Satz: „Länge bringt mehr als Komplexität“ spiegelt genau diesen Sachverhalt wider. Selbst für Passwörter, die mit einem aktuell, als sicher geltenden Hashverfahren wie PBKDF2 gespeichert werden, lassen sich bei 8 Zeichen länge mit maximaler Komplexität in etwa 196 Tagen, also einem guten halben Jahr, alle möglichen Varianten berechnen. Die Verlängerung des Passworts auf 12 Zeichen Groß-/Kleinschreibung würde diese Zeit auf über 153.482 Jahre verlängern. Taucht ein gehasht gespeichertes Passwort beispielsweise einer Liste der Top-Million-Passworte auf, dann ist es – unabhängig vom Hash-Algorithmus – in unter einer Sekunde erraten.
Am Ende bleibt…
Passwortvorgaben sind ein schwieriges Thema. Die BSI-Vorgaben mit 8 Zeichen sind – wenn man nur „online“-Angriffe berücksichtigt, durchaus akzeptabel. Eine Sicherheit gegenüber Angriffen auf Hash-Datenbanken sind sie garantiert nicht. Ist einmal eine Hash-Datenbank mit 8-stelligen Passwörtern in Umlauf geraten – was beinahe wöchentlich passiert – dann sind auch die verwendeten 8-stelligen Passwörter relativ schnell gebrochen und ein Angreifer kann mit nur einer einzigen Anfrage gegen einen Authentifizierungsdienst einen Account übernehmen. Nicht alle dieser Angriffe werden bekannt und tauchen sofort in Datenbanken wie haveibeenpwned.com auf – als Unternehmen der Anforderung nachzukommen, einen Passwort-Wechsel zu erzwingen, sobald das Passwort bekannt geworden ist, stellt also eine kaum erfüllbare Hürde dar. Und damit sind 8-stellige Passwörter eigentlich in der Praxis nicht verwendbar.
Natürlich werden bei Angriffen heute Brute-Force-Angriffe oft nur noch als letztes Mittel verwendet. Die unfassbar großen Wörterbücher und „geliebten“ Variationen von Passwörtern führen meist viel schneller zum Ziel. Beispiel?
- Ihr Passwort muss: mind. Eine Zahl enthalten, mind. 1 Sonderzeichen, Groß und Kleinbuchstaben und alle 3 Monate geändert werden:
- Firma2020!januar
- Firma2020!april
- Firma2020!juli
- Onlineshop!2020
- Onlineshop!2019
- …
Alle diese Passwörter entsprechen von Länge und Komplexität her den „üblichen“ Vorgaben. Auch eine Passwort-Historie von 24 Passworten wird für den Anwender kein Problem werden. Im Fall der quartalsweisen Passwort-Wechsel sind auch nahezu alle Filter machtlos, die etwa das Hochzählen von Monaten noch erkennen würden. Alternativ lassen sich auch mal deutsche und englische Monatsbezeichnungen mixen, um wirklich hartnäckige Passwortvergabefilter zu umgehen. Und ja: Der Mensch verwendet mitunter mehr Zeit darauf, sein mieses Passwort am Filter vorbei zu bekommen, als notwendig wäre, sich ein vernünftiges Passwort zu überlegen.
Empfehlungen
Die Empfehlungen mit den Augen eines Angreifers sind einfach:
- Multi-Faktor-Authentifizierung für alle Internet-erreichbaren Authentifizierungsdienste
- um die Wiederverwendung gebrochener Passwörter / geklauter Accounts zu verhindern
- Monitoring auf abgebrochene MFA-Vorgänge (!!!), um die Kompromittierung von Zugangsdaten zu erkennen
- Passwort-Länge von mind. 12 Zeichen
- um offline-Brute-Force-Angriffe unpraktikabel zu machen
- Passwort-Wechsel: mind. jährlich (auch für technische Benutzerkonten!)
- um evtl. unbemerkt kompromittierte Passwörter in den Griff zu bekommen
- Passwort-Historie: 1 Passwort
- um bei einem Wechsel tatsächlich ein neues Passwort zu erzwingen
- Verhinderung der Verwendung bekannter Passwörter / Top-Passwörter
- Um Rateversuche auf die tatsächliche Komplexität der Passwörter zu erschweren
- Verhinderung der Verwendung von Firmen-, Benutzer-, Domain- und Dienstnamen im Passwort
- Um intelligentes Raten der Passwörter zu erschweren
- Verbot zur Mehrfachverwendung der Passwörter
- Um die Auswirkungen von Passwort-Breaches zu reduzieren
- Passwort-Speicherung: Immer als Hash mit SALT
- um offline-Rainbow-Table-Angriffe zu erschweren
- Passwort-Hashverfahren: PBKDF2, BCRYPT o.ä.
- um offline-Brute-Force-Angriffe zu erschweren
- Anti-Automatisierung bei Passworteingabe: In allen Anmeldeformularen sind zwingend Maßnahmen zu ergreifen, wie eine zeitliche Verzögerungen von Anfragen, CAPTCHAs bei jeder Eingabe, IP-basierte Limits, temporäre Account-Sperren oder, oder, oder.
- um online-Brute-Force-Angriffe unpraktikabel zu machen
Der Rest, ist beim Benutzer ganz gut aufgehoben. Das Passwort „asdHohoHe291“ ist da am Ende nicht merklich schlechter oder besser als das Passwort „asd$HohoHebz“ – vor allem, wenn ein Angreifer in einem Brute-Force-Angriff keinen Schimmer hat, wie das Passwort aufgebaut sein könnte – und der Benutzer sich seine Passwörter auch noch merken kann und nicht auf einem Zettel am Monitor oder einer txt-Datei im OneDrive aufbewahrt.