Passwörter – Vorgaben, Angriffe, MFA und Praxis

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

  1. den regelmäßigen Passwort-Wechsel abschafft, muss
  2. 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:

 

Was / Wer BSI (für Bürger) CIS für Windows OWASP ASVS
Länge 8 mit MFA,
sonst 12
mind. 14 mind. 12
Historie
Komplexität Dar nicht in einschlägigen Listen oder Wörterbüchern vorkommen und nicht aus gängigen Varianten oder Zeichenwiederholungen bestehen Groß-/Kleinbuchstaben + Ziffern + Sonderzeichen;
Darf nicht den Benutzernamen enthalten
Keine Vorgaben
Maximale Gültigkeit / erzwungener Wechsel Bei Bekanntwerden des Passworts. Spätestens alle 60 Tage Keine zwingenden Passwortwechsel
Multi-Faktor-Authentifizierung Ja, sobald ein Dienst das ermöglicht bzw. bei administrativen Konten auch intern. Ja für alle administrativen Konten. Ja (ab ASVS Level 3)

 

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:

  1. 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]
  1. 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]
  2. 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.

 

Passwortlänge Komplexität / Zeichenraum Anzahl möglicher Werte Anzahl möglicher Werte (Exponenten-Darstellung)
8 52 53459728531456 5,35E+13
8 62 218340105584896 2,1834E+14
8 78 1370114370683140 1,37011E+15
12 52 390877006486250000000 3,90877E+20
12 62 3226266762397900000000 3,22627E+21
12 78 50714860157241000000000 5,07149E+22
16 52 2857942574656970000000000000 2,85794E+27
16 62 47672401706823500000000000000 4,76724E+28
16 78 1877213388752450000000000000000 1,87721E+30

 

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:

Passwörter - Microsoft-Authentication MFA

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:

Was Anzahl Hashes pro Sekunde
MD5 200.000.000.000
SHA256 23.012.000.000
NTLMv2 13.149.000.000
PBKDF2-HMAC-SHA256 (Azure PW Hash Sync) 80.756.000
MSCachev2 / DCC2 / Domain Cached Credentials (Windows 10 Domain-Passwort-Hashes) 2.552.000

 

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:

Mögl. Werte MD5 SHA256 PBKDF2 MSCachev2
8 (Groß-/Klein) 4 39 11033 349136
8 + Ziffern 18 158 45062 1425941
8 + Ziffern + Sonderzeichen 114 992 282768 8947978
12 (Groß-/Klein) 32573084 283096505 80670374644 2552749519895
12 + Ziffern 268855564 2336655341 665846657916 21070185229871
12 + Ziffern + Sonderzeichen 4226238346 36730734803 10466685686356 331209901758366
16 (Groß-/Klein) 238161881221414 2069892936045670 589830801974873000 18664724233653200000
16 + Ziffern 3972700142235290 34527204434515000 9838773941837870000 311340136538816000000
16 + Ziffern + Sonderzeichen 156434449062704000 1359590205655340000 387424956814859000000 12259753061340400000000

 

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.