Injection-Zeichen in Passwörtern: Warum das stärkste Passwort die Website zum Absturz bringt

Der Chef warf die Frage mit einem Grinsen auf den Tisch: Was wäre, wenn das beste Passwort dasjenige ist, das die Website zum Absturz bringt? Die Frage ist tiefsinniger, als sie klingt.

So denken die meisten Menschen über Injection-Zeichen in Passwörtern und Passwortsicherheit: etwas Langes wählen, Großbuchstaben einmischen, eine Zahl hinzufügen, vielleicht ein Ausrufezeichen. Die Ratschläge haben sich in zwanzig Jahren kaum verändert. Die eigentliche Bedrohung hat sich dagegen grundlegend gewandelt. Kein Angreifer setzt sich an eine Tastatur und tippt 500 Millionen Versuche von Hand. Moderne Passwort-Cracking-Hardware kann Milliarden von Hashes pro Sekunde testen. Die Länge Ihres Passworts zählt. Das Theater mit der Komplexität nicht.

Was wirklich zählt, und worüber kaum jemand spricht, ist das, was passiert, wenn Ihr Passwort Zeichen enthält, die für die Software hinter dem Login-Formular eine besondere Bedeutung haben. Zeichen wie ', ", ;, --, /, #, $ und |. Das sind nicht bloß Satzzeichen. Es sind Anweisungen in SQL, in Shell-Skripten, in der URL-Verarbeitung. Und wenn ein nachlässiger Entwickler ein Login-Formular baut, das Ihr Passwort direkt ohne Bereinigung in eine Datenbankabfrage schickt, hören diese Zeichen auf, Ihr Passwort zu sein, und werden zu Code.

Injection-Zeichen in Passwörtern: Wie ein Login-Formular zur Hintertür wird

Das klassische Beispiel ist die SQL-InjectionAngriff, bei dem schadhafter SQL-Code in ein Eingabefeld eingeschleust wird, um Datenbankabfragen zu manipulieren.. Stellen Sie sich eine Login-Seite vor, die Ihre Zugangsdaten so prüft:

SELECT * FROM users WHERE username = 'Sie' AND password = 'IhrPasswort'

Wenn Sie irgendwas' OR '1'='1 in das Passwortfeld eingeben, wird die Abfrage zu:

SELECT * FROM users WHERE username = 'Sie' AND password = 'irgendwas' OR '1'='1'

Da '1'='1' immer wahr ist, gibt die Datenbank jeden Benutzer zurück. Sie sind drin. Kein Passwort nötig. Wie die Web Security Academy von PortSwigger dokumentiert, kann sich ein Angreifer als beliebiger Benutzer einloggen, ohne das Passwort zu kennen, indem er einfach die SQL-Kommentarsequenz -- verwendet, um die Passwortprüfung vollständig zu umgehen.

Das ist kein theoretisches Problem. SQL-Injection steckt hinter einigen der größten Datenpannen der Geschichte. Es ist das, was OWASP als einen der häufigsten und gefährlichsten Angriffe auf Webanwendungen bezeichnet.

Der ironische Test: Wer Ihre Zeichen verbietet, kann sie wahrscheinlich nicht verarbeiten

Hier liegt die Pointe, auf die der Chef hinauswollte. Wenn eine Website Ihnen sagt, „Passwörter dürfen keine Sonderzeichen enthalten”, verrät sie Ihnen ungewollt etwas Wichtiges über ihre Sicherheit.

Eine ordentlich gebaute Anwendung kümmert sich nie darum, welche Zeichen in Ihrem Passwort stehen. Das Passwort wird gehasht, bevor es eine Datenbank berührt. Eine Hash-Funktion verwandelt P@$$w0rd';DROP TABLE-- in denselben kryptischen Zeichensalat fester Länge wie correcthorsebatterystaple. Die gefährlichen Zeichen verschwinden im Hashing-Prozess. Sie erreichen nie die SQL-Abfrage, den Shell-Befehl oder irgendetwas anderes.

Wenn eine Website Sonderzeichen verbietet, trifft eines von zwei Dingen zu: Entweder sind die Entwickler übertrieben vorsichtig bei einem Problem, das sie richtig lösen könnten, oder (beunruhigender) sie lassen Ihr Passwort durch Systeme laufen, die an diesen Zeichen würgen würden. Das zweite Szenario legt nahe, dass Ihr Passwort möglicherweise ohne ordentliche Bereinigung eine Datenbankabfrage, ein Shell-Skript oder ein Altsystem erreicht.

Der Sicherheitsforscher Daniel Miessler führt seit 2007 eine Liste der Schande über Websites, die Sonderzeichen ablehnen. Die ursprüngliche Liste enthielt große Banken wie Chase, Wells Fargo und Suntrust. Entwickler Scott Hanselman stieß auf einen Finanzdienstleister, der ihm mitteilte „Password should not contain any special characters, symbols or spaces” („Das Passwort darf keine Sonderzeichen, Symbole oder Leerzeichen enthalten”) und verwies auf die Absurdität: Eine Website, die Ihr Geld verwaltet, entmutigt aktiv starke Passwörter.

Was das NIST inzwischen sagt

Das US-amerikanische National Institute of Standards and Technology hat seine Passwortrichtlinien in SP 800-63B-4, veröffentlicht als Abschlussfassung im Jahr 2025, aktualisiert. Die Änderungen sind bedeutend. Das NIST verlangt nun, dass Systeme alle ASCII- und Unicode-Zeichen in Passwörtern akzeptieren, bis zu 64 Zeichen erlauben und eine Mindestlänge von 15 Zeichen durchsetzen. Obligatorische Komplexitätsregeln wurden ausdrücklich gestrichen: keine erzwungenen Großbuchstaben, keine vorgeschriebenen Sonderzeichen, keine periodischen Zurücksetzungen.

Die Begründung ist einleuchtend. Obligatorische Komplexitätsregeln veranlassten Menschen, Passwörter wie P@ssw0rd1! zu erstellen, die einem Richtlinienprüfer komplex erscheinen, für ein Cracking-Tool aber trivial sind. Länge und Zufälligkeit sind es, die Brute-Force-Angriffe wirklich abwehren.

Aber hier ist das, was das NIST richtig verstanden hat und das die meisten übersehen: Der Standard sagt, alle Zeichen zu akzeptieren. Er sagt nicht, sie zu verlangen. Der Punkt ist, dass nichts in Ihrem Passwort das System zum Absturz bringen sollte. Wenn es das tut, ist das System kaputt.

Die echte Bedrohung ist nicht das Raten, sondern das Lecken

Die größte Passwortgefahr im Jahr 2026 ist nicht, dass jemand Ihr Passwort errät. Es ist, dass das Unternehmen, das es speichert, es durchsickern lässt. 2019 gab Facebook zu, dass zwischen 200 Millionen und 600 Millionen Benutzerpasswörter im Klartext gespeichert worden waren, durchsuchbar von über 20.000 Mitarbeitern, mit Archiven bis zurück ins Jahr 2012. Nicht gehasht. Nicht verschlüsselt. Klartext.

Facebook war kein Einzelfall. Eine Analyse von F5 Labs aus dem Jahr 2021 ergab, dass Klartextspeicherung für die Mehrheit der Zugangsdaten-Lecks im Jahr 2020 verantwortlich war. Viele Organisationen speicherten Passwörter immer noch ohne jegliches Hashing oder verwendeten veraltete Algorithmen wie ungesalzenes MD5.

Wenn Passwörter im Klartext gespeichert werden, ist die Komplexität Ihres Passworts irrelevant. $uP3r_S3cur3!@#% und password123 sind gleichermaßen gefährdet. Die einzige Verteidigung ist, dort gar kein Konto zu haben.

Die praktische Schlussfolgerung

Was sollten Sie also konkret tun?

• Verwenden Sie einen Passwortmanager. Lassen Sie ihn lange, zufällige Passwörter generieren. 20 oder mehr Zeichen, beliebige Zeichen, die die Website akzeptiert.
• Testen Sie die Toleranz der Website. Wenn ein Registrierungsformular ', " oder ; in Ihrem Passwort ablehnt, ist das ein Signal. Es könnte übervorsichtiges Design sein, oder ein Warnsignal über die Sicherheitsarchitektur der Website.
• Behandeln Sie das Signal nicht als Beweis. Sonderzeichen abzulehnen ist verdächtig, aber sie zu akzeptieren garantiert auch keine gute Sicherheit. Viele Websites akzeptieren alles und speichern Passwörter trotzdem im Klartext.
• Verwenden Sie Zwei-Faktor-Authentifizierung überall, wo sie verfügbar ist. Ein geleaktes Passwort spielt viel weniger eine Rolle, wenn der Angreifer auch noch Ihr Telefon braucht.
• Verwenden Sie keine Passwörter mehrfach. Wenn eine Website Ihre Zugangsdaten leaked, ist jede andere Website, die dieses Passwort teilt, kompromittiert.

Die unbequeme Wahrheit ist, dass Passwortsicherheit größtenteils nicht in Ihren Händen liegt. Sie können alles richtig machen und trotzdem durch ein Unternehmen bloßgestellt werden, das Ihr Passwort in einer Tabellenkalkulation speichert. Die beste Verteidigung ist, zu minimieren, wie sehr Sie einem einzelnen Dienst mit Ihrem digitalen Leben vertrauen.

Die Frage funktioniert auch als Heuristik beim Penetrationstest: Was passiert, wenn Ihr Passwort selbst eine Injection-Nutzlast ist? Die Antwort verrät mehr über die Sicherheitslage einer Website als jede Datenschutzerklärung.

Die gängige Weisheit über Injection-Zeichen in Passwörtern und Passwortstärke konzentriert sich auf Entropie: längere Passwörter mit größeren Zeichensätzen widerstehen Brute-Force-Angriffen besser. Das stimmt, ist aber unvollständig. Die Hive Systems Passwort-Tabelle 2025 bewertet Cracking-Zeiten mit 12 RTX-5090-GPUs gegen bcrypt (Arbeitsfaktor 10). Ein 8-Zeichen-Passwort aus reinen Ziffern fällt in Sekunden. Ein 8-Zeichen-Passwort mit gemischten Zeichentypen hält Monate stand. Ein zufälliges 16-Zeichen-Passwort mit vollem ASCII-Umfang braucht geologische Zeit. Länge gewinnt.

Entropie ist jedoch nur eine Verteidigung gegen einen spezifischen Angriffsvektor: das Offline-Brute-Force-Knacken gestohlener Hashes. Sie sagt nichts darüber aus, was passiert, wenn das Passwort selbst als ausführbare Syntax interpretiert wird.

Injection-Zeichen in Passwörtern: Die Mechanik

Betrachten wir die klassische anfällige Login-Abfrage:

SELECT * FROM users WHERE username = '$user' AND password = '$pass'

Wenn $pass ohne parametrisierte AbfragenDatenbanktechnik, bei der Benutzereingaben getrennt von der Abfragestruktur verarbeitet werden, um Injection-Angriffe zu verhindern. oder ordentliches Escaping in diesen String eingebettet wird, bricht ein Passwort wie ' OR '1'='1 die Authentifizierungslogik zusammen. PortSwigger dokumentiert die spezifische Technik: administrator'-- als Benutzername mit leerem Passwort umschreibt die Abfrage zu SELECT * FROM users WHERE username = 'administrator'--' AND password = '' und kommentiert die Passwortprüfung vollständig aus.

SQL-InjectionAngriff, bei dem schadhafter SQL-Code in ein Eingabefeld eingeschleust wird, um Datenbankabfragen zu manipulieren. ist die bekannteste Variante, aber Passwortfelder können auch Vektoren sein für:

• OS-Befehlsinjektion. Wenn ein Backend-Skript das Passwort an einen Shell-Befehl weitergibt (üblich in älteren Authentifizierungssystemen, LDAP-Wrappern oder benutzerdefinierten Skripten), werden Zeichen wie ;, |, $(...) und Backticks zu Befehlsinjektionsvektoren. Ein Passwort mit ; rm -rf / könnte in einer katastrophal schlechten Implementierung auf dem Server ausgeführt werden.
• LDAP-Injection. Zeichen wie *, (, ) und haben in LDAP-Abfragen eine besondere Bedeutung. Unsanitisierte Passworteingabe bei einer LDAP-Bind-Operation kann die Abfragelogik verändern.
• XPath-Injection. Wenn die Authentifizierung einen XML-Datenspeicher nutzt, können ' und " XPath-Ausdrücke auf dieselbe Weise brechen wie SQL.

Der gemeinsame Nenner: Das Passwort wird als Teil einer Kontrollstruktur behandelt statt als opake Daten. Die richtige Verteidigung ist seit Jahrzehnten bekannt: parametrisierte Abfragen für SQL, ordentliches Escaping für Shell-Befehle und die OWASP-Empfehlung, niemals Befehle aus verketteten Benutzereingaben zu konstruieren.

Die Zeichenablehnungs-Heuristik

Wenn eine Website Sonderzeichen in Passwörtern ablehnt, offenbart sie eines von drei Dingen:

1. Defense in Depth falsch angewendet. Die Entwickler kennen Injection, haben aber Eingabebeschränkung statt ordentlicher Bereinigung gewählt. Das ist der beste Fall und trotzdem ein Verstoß gegen die OWASP-Passwortrichtlinien, die 33 Sonderzeichen auflisten, die akzeptiert werden sollten.
2. Passwörter treffen auf unsanitisierte Code-Pfade. Die Zeichen werden abgelehnt, weil sie flussabwärts Fehler oder unerwartetes Verhalten verursachen: in SQL, in Shell-Skripten, in Legacy-Middleware. Das bedeutet, das Passwort durchläuft diese Systeme in einer Form, die als Code interpretiert werden könnte.
3. Passwörter werden im Klartext gespeichert oder verglichen. Wenn das Passwort vor jeder Verarbeitung gehasht würde, wären die Sonderzeichen irrelevant. Ein bcrypt-Hash von '; DROP TABLE users;-- ist eine harmlose 60-Zeichen-Zeichenkette. Zeichenbeschränkungen deuten darauf hin, dass das rohe Passwort länger in der Verarbeitungspipeline verbleibt, als es sollte.

Daniel Miesslers „Liste der Schande” von 2007 nannte Chase, Wells Fargo und American Express unter den Banken, die Sonderzeichen ablehnten. Scott Hanselman meldete einen Finanzdienstleister, der Benutzer anwies „Password should not contain any special characters, symbols or spaces” („Das Passwort darf keine Sonderzeichen, Symbole oder Leerzeichen enthalten”). Ein Kommentator in diesem Beitrag stellte fest, dass Verizon einst Sonderzeichen bei der Registrierung verlangte, sie beim Login aber ablehnte, ein Verhalten, das mit einem System konsistent ist, in dem zwei verschiedene Code-Pfade dasselbe Passwort unterschiedlich behandeln.

NIST SP 800-63B-4: Der Standard stimmt nun zu

NIST SP 800-63B-4 (finalisiert August 2025) kodifiziert, was Sicherheitspraktiker seit Jahren fordern. Die wichtigsten Anforderungen für passwortbasierte Authentifizierung:

• Verifikatoren MÜSSEN alle druckbaren ASCII-Zeichen, das Leerzeichen und Unicode-Zeichen akzeptieren.
• Mindestpasswortlänge: 15 Zeichen (wenn das Passwort der einzige Authentifikator ist).
• Maximale Länge: mindestens 64 Zeichen.
• Keine Kompositionsregeln (keine obligatorischen Großbuchstaben, Ziffern oder Sonderzeichen).
• Keine periodischen Passwortwechsel, sofern kein Hinweis auf Kompromittierung vorliegt.

Der Entwurf vom September 2024, der der Abschlussfassung vorausging, stellte ausdrücklich fest: „Humans have a limited ability to memorize complex, arbitrary secrets, so they often choose passwords that can be easily guessed.” („Menschen haben eine begrenzte Fähigkeit, komplexe, willkürliche Geheimnisse zu memorieren, deshalb wählen sie oft leicht zu erratende Passwörter.”) Der Wandel geht von der Vorschrift für Komplexität (die P@ssw0rd1! erzeugt) hin zur Vorschrift für Länge und Zeichenakzeptanz (was correct horse battery staple und seine 44 Bit Entropie ermöglicht).

Das Speicherproblem übertrifft das Rateproblem

Offline-Cracking ist eine ernsthafte Bedrohung, erfordert aber eine gestohlene Hash-Datenbank. Das häufigere Versagen ist weit schlichter: Passwörter, die in wiederherstellbarer Form gespeichert werden.

Im März 2019 berichtete Brian Krebs, dass Facebook zwischen 200 und 600 Millionen Passwörter im Klartext gespeichert hatte, durchsuchbar von über 20.000 Mitarbeitern. Zugriffsprotokolle zeigten rund 9 Millionen interne Abfragen auf Daten mit Klartextpasswörtern. Archive reichten bis 2012 zurück.

Facebook war kein Ausreißer. Der F5 Labs Credential StuffingEin Cyberangriff, bei dem automatisierte Tools gestohlene Benutzername-Passwort-Kombinationen massenhaft gegen Websites testen und dabei ausnutzen, dass viele Nutzer dieselben Zugangsdaten mehrfach verwenden. Report 2021, zusammengefasst von Securden, ergab, dass Klartextspeicherung die Mehrheit der Zugangsdaten-Lecks im Jahr 2020 ausmachte. Organisationen verwendeten weiterhin schwache Hashing-Verfahren (MD5, SHA-1 ohne Salting) oder gar kein Hashing. Gegen die Hive-Systems-Benchmarks fällt ein MD5-gehashtes Passwort um Größenordnungen schneller als ein bcrypt-gehashtes gleicher Länge und Komplexität.

Wenn Passwörter im Klartext oder mit schwachem Hashing gespeichert werden, ist die Entropie Ihres Passworts irrelevant. Alle Passwörter sind gleich kompromittiert. Die einzige Verteidigung ist Zugangsdaten-Isolation: einzigartige Passwörter pro Dienst, verwaltet durch einen Passwortmanager, mit Zwei-Faktor-Authentifizierung als Rückfallebene.

Die Diagnose

Die ursprüngliche Beobachtung hält als praktische Heuristik stand:

• Versuchen Sie, sich mit Sonderzeichen in Ihrem Passwort zu registrieren. Zeichen wie ', ", ;, --, $ und | sind der minimale Testsatz. Wenn die Website sie ablehnt, ist sie entweder übervorsichtig oder tatsächlich anfällig.
• Akzeptanz ist notwendig, aber nicht hinreichend. Eine Website kann ' in einem Passwort akzeptieren und es trotzdem im Klartext speichern. Der Test schließt die schlimmsten Täter aus, zertifiziert aber nicht die übrigen.
• Wenn eine Website keine Standard-Satzzeichen in einem Passwortfeld verarbeiten kann, fragen Sie sich, was sie sonst noch nicht verarbeiten kann. Passworteingabe ist die einfachste Benutzereingabe, die eine Webanwendung verarbeitet. Wenn sie das falsch machen, ist die AngriffsflächeDie Gesamtheit der Punkte in einem System, an denen ein Angreifer versuchen kann einzudringen, Daten zu extrahieren oder Schaden anzurichten. wahrscheinlich breiter als nur das Login-Formular.

Die zugrunde liegende Logik ist stichhaltig: Wenn die Entwickler zu faul waren, ein Passwortfeld ordentlich zu parametrisieren, gibt es wenig Grund anzunehmen, dass sie es gehasht, gesalzen oder die Datenbank, in der es lebt, gesichert haben. Das stärkste Passwort ist nicht nur lang und zufällig. Es ist eines, das ein schlecht gebautes System zum Absturz bringen würde. Und wenn es das System zum Absturz bringt, haben Sie Ihre Antwort: Legen Sie dort kein Konto an.