123456 Passwort Unsicher: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Das Passwort 123456 gehört seit Jahren zu den bekanntesten Beispielen für ein praktisch wertloses Kennwort. Der Grund ist nicht nur, dass es kurz und simpel ist. Entscheidend ist, dass es in nahezu jeder geleakten Passwortsammlung enthalten ist, in Standard-Wortlisten für Angriffe ganz oben steht und von Angreifern automatisiert zuerst getestet wird. Wer 123456 verwendet, setzt nicht auf ein schwaches Passwort im theoretischen Sinn, sondern auf ein Passwort, das in realen Angriffsszenarien mit hoher Wahrscheinlichkeit innerhalb von Sekunden kompromittiert wird.

Aus Sicht eines Pentesters ist 123456 kein Sonderfall, sondern ein Muster. Solche Passwörter tauchen in internen Audits, bei Passwortspraying, in kompromittierten Alt-Accounts, bei Testzugängen und in schlecht gepflegten Legacy-Systemen immer wieder auf. Besonders kritisch wird es, wenn Organisationen glauben, dass nur externe Angreifer gefährlich sind. Tatsächlich reichen oft schon interne Fehlkonfigurationen, unzureichende Passwort-Policies oder fehlende Kontrollen, damit triviale Kennwörter unentdeckt produktiv bleiben.

123456 ist deshalb so gefährlich, weil es mehrere Schwächen gleichzeitig vereint: geringe Länge, keine Unvorhersehbarkeit, hohe Popularität und maximale Wiedererkennbarkeit in Passwortlisten. Wer verstehen will, warum das problematisch ist, sollte nicht nur auf Komplexitätsregeln schauen, sondern auf reale Angriffsmodelle wie Was Ist Dictionary Attack, Was Ist Brute Force und Was Ist Credential Stuffing. In allen drei Fällen ist 123456 ein Kandidat mit extrem hoher Trefferwahrscheinlichkeit.

Ein häufiger Denkfehler lautet: Ein einzelnes simples Passwort sei nur dann kritisch, wenn ein gezielter Angriff stattfindet. In der Praxis laufen Angriffe aber massenhaft, automatisiert und ohne manuelle Auswahl. Bots testen Millionen Kombinationen gegen Login-Portale, VPNs, Webmailer, Shops, Foren und Admin-Oberflächen. Dabei werden nicht zuerst komplexe Kombinationen ausprobiert, sondern die wahrscheinlichsten Treffer. Genau deshalb ist 123456 so gefährlich: Es ist nicht nur leicht zu erraten, sondern statistisch hochpriorisiert.

Wer sich mit Meistgenutzte Passwoerter oder Unsichere Passwoerter Liste beschäftigt, erkennt schnell, dass 123456 nicht zufällig immer wieder auftaucht. Es ist ein Paradebeispiel für menschlich vorhersehbare Muster. Menschen wählen einfache Sequenzen, Tastaturmuster oder bekannte Standardwörter. Genau diese Vorhersagbarkeit ist der Kern des Problems.

Angreifer arbeiten selten blind. Sie nutzen Wahrscheinlichkeiten, Datenleaks, Passwortlisten und Automatisierung. 123456 ist in praktisch jeder relevanten Wortliste enthalten, etwa in Sammlungen wie RockYou oder aus neueren Leaks. Solche Listen werden nicht einfach nur abgespielt, sondern oft gewichtet, dedupliziert, nach Sprache, Region, Plattform oder Zielgruppe angepasst und mit Benutzernamen, Jahreszahlen oder Unternehmensbegriffen kombiniert.

Bei einem Online-Angriff gegen ein Login-Formular ist 123456 oft unter den ersten Kandidaten. Das gilt besonders bei Passwortspraying, wo wenige häufige Passwörter gegen viele Konten getestet werden, um Sperrmechanismen zu umgehen. Statt ein Konto mit tausenden Versuchen zu bombardieren, testet der Angreifer ein Passwort wie 123456 gegen hunderte oder tausende Benutzerkonten. Wenn auch nur ein kleiner Prozentsatz erfolgreich ist, entsteht sofort ein Einstiegspunkt.

Bei Offline-Angriffen nach einem Datenbank-Leak ist die Lage noch kritischer. Sobald Passwort-Hashes in die Hände eines Angreifers gelangen, werden zuerst die billigsten Kandidaten geprüft. Wenn die Anwendung schwache oder veraltete Hash-Verfahren verwendet, etwa unsalted SHA-256 oder MD5, fällt 123456 extrem schnell. Selbst bei besseren Verfahren bleibt ein triviales Passwort problematisch, weil es in jeder priorisierten Kandidatenliste enthalten ist. Mehr dazu zeigen Passwort Hashing Erklaert, Sha256 Passwort Unsicher und Argon2 Erklaert.

Typische Angriffswege, bei denen 123456 sofort relevant wird:

• Online-Login-Angriffe gegen Webportale, VPNs, Mailzugänge und Admin-Interfaces
• Offline-Hash-Cracking nach Datenbank-Leaks oder kompromittierten Backups
• Credential Stuffing mit bekannten E-Mail-Passwort-Kombinationen aus früheren Vorfällen

In Pentests zeigt sich regelmäßig, dass nicht nur Endnutzerkonten betroffen sind. Auch Service-Accounts, Testkonten, Demo-Zugänge, lokale Administratoren oder Geräte-Webinterfaces verwenden erschreckend oft triviale Kennwörter. Besonders gefährlich ist das bei Systemen, die nicht zentral überwacht werden. Ein einzelner erfolgreicher Login mit 123456 kann ausreichen, um interne Netze zu pivotieren, Konfigurationen auszulesen oder weitere Zugangsdaten zu erbeuten.

Die technische Ausnutzung ist also nicht spektakulär, sondern effizient. Genau das macht schwache Passwörter so gefährlich: Sie erfordern keine ausgefeilte Zero-Day-Lücke, sondern nur gute Vorbereitung, Standard-Tooling und Geduld.

Viele Nutzer glauben, dass ein Passwort erst dann unsicher ist, wenn es nur aus Zahlen besteht. Das greift zu kurz. Das eigentliche Problem bei 123456 ist die Kombination aus geringer Länge und maximaler Vorhersagbarkeit. Ein Passwort kann formal Sonderzeichen oder Großbuchstaben enthalten und trotzdem schwach sein, wenn es einem bekannten Muster folgt. Umgekehrt kann eine lange, zufällige oder gut gewählte Passphrase deutlich robuster sein als ein kurzes, künstlich verkompliziertes Kennwort.

123456 hat praktisch keine wirksame Entropie im realen Angriffsmodell. Theoretische Kombinationsräume helfen wenig, wenn ein Passwort in den ersten Zeilen jeder Angriffsliste steht. Deshalb ist die Unterscheidung zwischen mathematischer Zeichenraum-Betrachtung und realer Passwortstärke entscheidend. Wer nur auf Regeln wie mindestens eine Zahl, ein Sonderzeichen und ein Großbuchstabe setzt, übersieht, dass Angreifer genau diese Muster längst in ihre Kandidatengenerierung eingebaut haben.

Ein Beispiel: Das Passwort 123456! wirkt auf den ersten Blick minimal besser als 123456. In der Praxis ist es kaum sicherer, weil Varianten mit angehängtem Sonderzeichen Standardkandidaten sind. Dasselbe gilt für 12345678, 123456789 oder 123456a. Solche Erweiterungen erhöhen nicht die Unvorhersehbarkeit, sondern folgen bekannten Nutzergewohnheiten. Wer tiefer verstehen will, warum das so ist, sollte sich mit Passwort Entropie Erklaert, Passwort Laenge Oder Komplexitaet und Passphrase Vs Passwort beschäftigen.

Aus technischer Sicht ist ein starkes Passwort nicht einfach nur komplex, sondern teuer zu erraten. Teuer bedeutet: Es taucht nicht in Leaks auf, ist nicht aus persönlichen Daten ableitbar, folgt keinem Standardmuster und bleibt auch bei priorisierten Angriffen unwahrscheinlich. Genau hier versagt 123456 vollständig.

Ein weiterer Fehler in vielen Umgebungen ist die Überschätzung von Passwort-Checkern, die nur oberflächliche Regeln prüfen. Wenn ein System 123456 wegen fehlender Mindestlänge ablehnt, ist das gut. Wenn es aber 123456! oder Sommer2024! als stark bewertet, obwohl diese Muster in realen Wortlisten vorkommen, entsteht Scheinsicherheit. Deshalb müssen Prüflogiken nicht nur Syntax, sondern auch bekannte schwache Muster, Leaks und Kontext berücksichtigen.

Schwache Passwörter bleiben nicht deshalb im Einsatz, weil das Risiko unbekannt wäre. Sie bleiben im Einsatz, weil Nutzer und teilweise auch Administratoren falsche Annahmen treffen. Eine der häufigsten lautet: Das Konto sei nicht wichtig genug, um angegriffen zu werden. In der Praxis werden aber nicht nur wertvolle Konten direkt missbraucht. Ein scheinbar unwichtiges Konto kann als Ausgangspunkt für Seitwärtsbewegungen, Passwort-Resets, Social Engineering oder Datensammlung dienen.

Eine weitere Fehlannahme lautet: Wenn ein Login durch Rate Limits geschützt ist, sei 123456 weniger problematisch. Das stimmt nur teilweise. Rate Limits helfen gegen bestimmte Online-Angriffe, aber nicht gegen Credential Stuffing mit verteilten Quellen, nicht gegen kompromittierte Session-Cookies, nicht gegen Phishing und schon gar nicht gegen Offline-Cracking nach einem Leak. Außerdem sind viele Schutzmechanismen fehlerhaft implementiert oder gelten nicht für alle Authentifizierungswege.

Besonders gefährlich sind diese Denkfehler:

• Das Passwort sei akzeptabel, weil zusätzlich ein Sonderzeichen angehängt wurde
• Das Konto sei unkritisch, obwohl es Passwort-Reset-Ketten oder interne Berechtigungen beeinflusst
• Ein starkes Hashing-Verfahren allein könne ein extrem schwaches Passwort kompensieren

Auch die Aussage, ein Passwort werde regelmäßig geändert und sei deshalb ausreichend sicher, ist problematisch. Wenn Nutzer aus 123456 einfach 1234567 oder 123456! machen, bleibt das Muster trivial. Schlechte Rotationen erzeugen oft nur vorhersehbare Varianten. Sinnvoller ist eine robuste Erstwahl, ergänzt durch MFA, Leak-Erkennung und saubere Incident-Prozesse. Dazu passen Passwort Rotation Sinnvoll und Multi Factor Authentication Erklaert.

Ein weiterer Punkt aus der Praxis: Viele Teams prüfen Passwortqualität nur bei der Kontoerstellung, nicht aber bei Importen, Migrationen, API-basierten Benutzeranlagen oder lokalen Notfallkonten. Genau dort tauchen dann triviale Kennwörter auf. In Audits sind es oft nicht die normalen Benutzerkonten, sondern Ausnahmen, Altlasten und Sonderprozesse, die das größte Risiko erzeugen.

Ein typisches Szenario aus internen Sicherheitsprüfungen: Ein Unternehmen betreibt ein zentrales SSO-System, mehrere Fachanwendungen und ein älteres Intranet mit separater Benutzerverwaltung. Die zentrale Plattform erzwingt moderne Passwortregeln, das Alt-System jedoch nicht. Ein Benutzer verwendet dort 123456, weil das Konto selten genutzt wird. Durch ein Datenleck in einer Drittanwendung wird die E-Mail-Adresse des Benutzers bekannt. Ein Angreifer testet Standardpasswörter gegen das Alt-System, erhält Zugriff und findet dort interne Dokumente, Kontaktlisten und technische Hinweise auf weitere Systeme.

Der eigentliche Schaden entsteht nicht durch das einzelne schwache Passwort, sondern durch die Kette danach. Aus dem kompromittierten Konto werden Namenskonventionen, interne URLs und Rollenmodelle sichtbar. Mit diesen Informationen wird ein gezielteres Password Spraying gegen andere Dienste durchgeführt. Parallel startet der Angreifer Phishing-Mails mit glaubwürdigem internen Bezug. Das schwache Passwort war nicht das Endziel, sondern der erste Hebel.

In der Incident Response zeigt sich dann oft ein bekanntes Muster: Logs sind unvollständig, das Alt-System hat keine brauchbaren Alarmierungen, Passwortänderungen werden nicht zentral korreliert und betroffene Konten wurden in mehreren Anwendungen wiederverwendet. Genau deshalb ist Passwort Wiederverwendung Risiko so kritisch. Ein triviales Passwort wie 123456 ist selten isoliert. Es ist oft Teil eines größeren Hygieneproblems.

Ein realistischer Prüfablauf in einem autorisierten Audit kann so aussehen:

1. Identifikation externer und interner Login-Oberflächen
2. Prüfung auf Passwort-Policy-Unterschiede zwischen Systemen
3. Erkennung fehlender Sperrmechanismen oder schwacher Rate Limits
4. Test mit genehmigten Standardpasswortlisten gegen definierte Konten
5. Auswertung von Logging, Alarmierung und Reaktionszeit
6. Prüfung auf Passwort-Wiederverwendung und Alt-Accounts

Entscheidend ist dabei nicht nur, ob 123456 funktioniert, sondern warum es funktionieren konnte. War die Policy zu schwach? Wurde ein Legacy-System vergessen? Gab es keine Blacklist für bekannte schlechte Passwörter? Wurde MFA nicht erzwungen? Ohne diese Ursachenanalyse bleibt jede Korrektur oberflächlich.

Wer heute noch 123456 oder ähnliche Muster verwendet, braucht keinen kosmetischen Austausch, sondern einen sauberen Workflow. Ziel ist nicht nur ein neues Passwort, sondern ein belastbares System für alle Konten. Der erste Schritt ist die Priorisierung: E-Mail-Konten, Passwort-Manager, Banking, Cloud-Speicher, Unternehmenszugänge und Social-Media-Konten mit Reset-Funktion müssen zuerst abgesichert werden. Danach folgen alle weiteren Dienste.

Ein sinnvoller Nutzer-Workflow beginnt mit einer Bestandsaufnahme. Welche Konten existieren? Wo wurden Passwörter wiederverwendet? Welche Dienste sind besonders kritisch? Danach werden starke, einzigartige Kennwörter erzeugt, idealerweise mit einem Passwort-Manager. Für besonders sensible Konten wird zusätzlich MFA aktiviert. Wer unsicher ist, wie starke Kennwörter konkret aussehen, findet Orientierung bei Sichere Passwoerter Erstellen, Was Ist Ein Starkes Passwort und Passwort Manager Sicherheit.

Praktisch bewährt hat sich folgender Ablauf:

• Zuerst alle kritischen Konten identifizieren und Passwörter dort sofort ersetzen
• Für jedes Konto ein einzigartiges Passwort oder eine starke Passphrase verwenden
• MFA aktivieren und Wiederherstellungsoptionen wie Backup-Codes sicher ablegen

Wichtig ist, nicht in alte Muster zurückzufallen. Ein Passwort wie 123456Banking!, 123456Mail! oder 1234562026! ist keine Verbesserung, sondern nur eine leicht modifizierte Schwäche. Ebenso problematisch sind persönliche Muster wie Vorname+Geburtsjahr oder Firmenname+Sonderzeichen. Solche Konstruktionen wirken individuell, sind aber in realen Angriffen gut modellierbar.

Ein sauberer Workflow umfasst auch die Prüfung auf kompromittierte Konten. Wenn ein Passwort wie 123456 verwendet wurde, sollte nicht nur geändert werden. Es muss geprüft werden, ob bereits unbefugte Zugriffe stattgefunden haben, ob Weiterleitungen eingerichtet wurden, ob Recovery-Daten manipuliert wurden und ob Sessions auf anderen Geräten aktiv sind. Besonders bei E-Mail-Konten ist das essenziell, weil sie oft als Dreh- und Angelpunkt für Passwort-Resets dienen.

In Unternehmensumgebungen reicht es nicht, Nutzer zu besseren Passwörtern aufzufordern. Es braucht technische Leitplanken, Monitoring und belastbare Prozesse. Eine gute Passwort-Policy verhindert nicht nur kurze Kennwörter, sondern blockiert bekannte schlechte Passwörter, erkennt Wiederverwendung, erzwingt MFA für kritische Rollen und berücksichtigt Sonderfälle wie Service-Accounts, lokale Administratoren und Legacy-Systeme.

Aus Sicht der Verteidigung ist 123456 ein Indikator für Governance-Schwächen. Wenn ein solches Passwort produktiv existiert, fehlt meist mehr als nur eine Regel. Häufig fehlen Blacklists, zentrale Identitätsverwaltung, Audit-Prozesse oder Awareness-Maßnahmen. Unternehmen sollten deshalb nicht nur Policies formulieren, sondern ihre Wirksamkeit testen. Relevante Themen sind Passwort Richtlinien Best Practice, Passwort Audit Durchfuehren und Active Directory Passwort Policy.

Ein belastbarer Unternehmens-Workflow umfasst mehrere Ebenen. Erstens müssen schwache Passwörter bei der Vergabe blockiert werden. Zweitens müssen bestehende Konten regelmäßig auf Risikoindikatoren geprüft werden. Drittens müssen Anmeldeversuche, Passwortänderungen und verdächtige Muster zentral überwacht werden. Viertens müssen Incident-Response-Prozesse klar definieren, wie bei Verdacht auf Passwortkompromittierung reagiert wird.

Besonders kritisch sind privilegierte Konten. Ein Admin-Account mit schwachem Passwort ist kein normales Einzelrisiko, sondern potenziell ein vollständiger Kontrollverlust. Für solche Konten gelten strengere Anforderungen: lange, einzigartige Passwörter, MFA, getrennte Admin-Identitäten, eingeschränkte Nutzung, sichere Speicherung und engmaschiges Monitoring. Dasselbe gilt für Notfallkonten, Break-Glass-Accounts und technische Konten mit weitreichenden Rechten.

Ein häufiger Fehler in Unternehmen ist die Annahme, dass Passwort-Policies allein genügen. In der Praxis müssen Policies mit technischen Kontrollen gekoppelt werden: Login-Drosselung, IP-Reputation, Anomalieerkennung, Session-Management, sichere Passwortspeicherung, Härtung von Reset-Prozessen und Schutz vor Enumeration. Erst das Zusammenspiel reduziert das Risiko wirklich.

Moderne Passwortspeicherung ist Pflicht, aber sie ersetzt keine Passwortqualität. Wenn ein Dienst Passwörter mit Argon2id oder bcrypt speichert, ist das deutlich besser als SHA-256 oder MD5. Dennoch bleibt 123456 ein schlechtes Passwort. Der Unterschied liegt in der Kostenstruktur für den Angreifer. Gute Verfahren machen das Testen vieler Kandidaten teurer, aber sie ändern nichts daran, dass 123456 in jeder priorisierten Kandidatenliste ganz vorne steht.

Salting verhindert, dass identische Passwörter über verschiedene Konten denselben Hash erzeugen, und erschwert vorberechnete Tabellen. Peppering kann zusätzlichen Schutz bringen, wenn es sauber umgesetzt wird. Aber weder Salt noch Pepper erhöhen die inhärente Stärke des Passworts selbst. Wenn ein Angreifer einen Hash mit einem Kandidaten wie 123456 testet, bleibt der Versuch billig im Vergleich zu langen, unvorhersehbaren Passphrasen. Deshalb müssen Passwortqualität und sichere Speicherung immer zusammen gedacht werden.

Ein vereinfachtes Beispiel zeigt den Unterschied:

Schwaches Passwort: 123456
Hash-Verfahren: Argon2id mit guten Parametern
Ergebnis: besser geschützt als bei SHA-256, aber weiterhin früher Kandidat im Angriff

Starkes Passwort: z7!M4qL9#vP2rT8x
Hash-Verfahren: Argon2id mit guten Parametern
Ergebnis: hoher Aufwand durch starkes Passwort plus teures Hashing

In Audits wird oft sichtbar, dass Teams zwar moderne Bibliotheken einsetzen, aber gleichzeitig schlechte Passwörter zulassen oder keine Blacklists gegen bekannte Leaks verwenden. Das ist ein klassischer Architekturfehler. Sichere Speicherung ist die letzte Verteidigungslinie, nicht die erste. Wer die Zusammenhänge vertiefen will, sollte Salting Passwoerter, Peppering Passwoerter und Bcrypt Erklaert im Zusammenhang betrachten.

Auch Rainbow Tables werden oft missverstanden. Gegen korrekt gesalzene moderne Hashes sind klassische Rainbow Tables weitgehend irrelevant. Das bedeutet aber nicht, dass schwache Passwörter sicher wären. Heute dominieren GPU-gestützte Kandidatenangriffe, regelbasierte Mutation und intelligente Wortlisten. Ein Passwort wie 123456 fällt nicht wegen exotischer Kryptanalyse, sondern wegen seiner trivialen Vorhersagbarkeit.

Schwache Passwörter wie 123456 müssen zuverlässig erkannt werden, bevor sie produktiv genutzt werden. Dafür reichen einfache Regex-Regeln nicht aus. Gute Prüfsysteme kombinieren Mindestanforderungen mit Blacklists, Leckdaten, Mustererkennung und Kontextbewertung. Ein Passwort-Checker sollte nicht nur zählen, welche Zeichentypen vorkommen, sondern bewerten, ob das Kennwort in bekannten Listen auftaucht, ob es Sequenzen enthält, ob es auf Tastaturmustern basiert oder ob es aus leicht ableitbaren Bestandteilen besteht.

In der Praxis ist auch die Betriebsform relevant. Ein Online-Checker kann nützlich sein, wenn er datensparsam und technisch sauber arbeitet. Für sensible Umgebungen sind lokale oder clientseitige Prüfungen oft vorzuziehen. Entscheidend ist, dass keine echten Passwörter unnötig übertragen oder gespeichert werden. Wer solche Werkzeuge einsetzen will, sollte die Unterschiede zwischen Passwort Checker Online Vs Offline, Passwort Checker Client Side und Passwort Checker Ist Das Sicher verstehen.

Ein guter Testprozess bewertet nicht nur einzelne Passwörter, sondern den gesamten Workflow. Dazu gehört die Frage, ob schwache Passwörter bei Registrierung, Passwortänderung, API-Anlage, SSO-Fallback und Admin-Reset gleichermaßen blockiert werden. Ebenso wichtig ist die Messung von False Positives und False Negatives. Ein Checker, der 123456 zuverlässig erkennt, aber triviale Varianten wie 123456! oder Qwertz2024! durchwinkt, ist nur begrenzt brauchbar.

Für Unternehmen empfiehlt sich ein mehrstufiger Ansatz: präventive Prüfung bei der Eingabe, regelmäßige Audits gegen bekannte schwache Muster, Monitoring verdächtiger Login-Versuche und Reaktion auf Leckdaten. Für Endnutzer gilt: Ein Checker ist nur ein Hilfsmittel. Die eigentliche Sicherheit entsteht durch Einzigartigkeit, Länge, Passwort-Manager und MFA.

Wer 123456 testet und ein System akzeptiert dieses Passwort, hat bereits einen klaren Befund: Die Schutzmechanismen sind unzureichend. Dann sollte nicht nur das Passwort ersetzt, sondern die gesamte Policy und Implementierung überprüft werden.

Die Bewertung ist eindeutig: 123456 ist nicht nur unsicher, sondern in realen Angriffen praktisch sofort verwertbar. Wer ein solches Passwort verwendet oder in einer Umgebung zulässt, muss von einem erhöhten Kompromittierungsrisiko ausgehen. Die Gegenmaßnahmen sind bekannt, aber sie müssen konsequent umgesetzt werden.

Für Endnutzer bedeutet das: keine Wiederverwendung, keine simplen Muster, keine kosmetischen Varianten, stattdessen starke einzigartige Passwörter oder Passphrasen mit Passwort-Manager und MFA. Für Unternehmen bedeutet es: schwache Passwörter technisch blockieren, Alt-Systeme einbeziehen, privilegierte Konten härten, Leckdaten auswerten und Anomalien überwachen.

Ein robuster Minimalstandard sieht so aus:

- bekannte schwache Passwörter aktiv blockieren
- lange und einzigartige Passwörter oder Passphrasen verwenden
- MFA für kritische und möglichst alle relevanten Konten aktivieren
- moderne Hash-Verfahren wie Argon2id oder bcrypt einsetzen
- Passwort-Wiederverwendung organisatorisch und technisch reduzieren
- Login- und Reset-Prozesse überwachen und härten

Wer von 123456 weg will, sollte nicht nur ein neues Passwort setzen, sondern das gesamte Authentifizierungsmodell verbessern. Dazu gehören sichere Wiederherstellungswege, Schutz des E-Mail-Kontos, Überprüfung aktiver Sessions, Kontrolle von Weiterleitungen und die Absicherung aller Konten mit hohem Hebel. Besonders wichtig ist die Einsicht, dass Passwortsicherheit kein Einzelereignis ist. Sie ist ein laufender Prozess aus Auswahl, Speicherung, Nutzung, Überwachung und Reaktion.

Am Ende bleibt eine einfache technische Wahrheit: 123456 scheitert an jedem realistischen Sicherheitsmaßstab. Es ist kurz, bekannt, massenhaft geleakt, leicht zu testen und in Angriffswerkzeugen fest verankert. Wer ernsthaft Konten schützen will, darf solche Passwörter weder verwenden noch akzeptieren.