passwort-pruefen

Von DES bis Argon2: Eine kurze Geschichte der Passwort-Sicherheit

Sechs Jahrzehnte trennen das erste digitale Passwort am MIT von Argon2id und Passkeys. Dazwischen liegen DES, Salt-Verfahren, MD5-Kollisionen, der bcrypt-Durchbruch und ein NIST, das seine Sonderzeichen-Pflicht von 2003 selbst einkassierte. Dieser Überblick zeichnet die Algorithmen, die Datenleaks und die Standards nach, die die heutige Passwort-Hygiene geformt haben.

Sechs Jahrzehnte trennen das erste digitale Passwort am MIT von Argon2id und Passkeys. Dazwischen liegen DES, Salt-Verfahren, MD5-Kollisionen, der bcrypt-Durchbruch und ein NIST, das seine Sonderzeichen-Pflicht von 2003 selbst einkassierte. Dieser Überblick zeichnet die Algorithmen, die Datenleaks und die Standards nach, die die heutige Passwort-Hygiene geformt haben.

Die Anfänge: Multics und das erste digitale Passwort

Den Schritt von Lochkarten zu interaktiven Sitzungen markierte das Compatible Time-Sharing System am MIT 1961. Fernando Corbató rüstete CTSS mit Login-Konten aus, weil mehrere Forscher sich denselben Mainframe teilten. Die Passwörter lagen zunächst in einer Klartextdatei, was bereits 1962 zum ersten dokumentierten Passwort-Leak führte: ein Programmierfehler druckte die Datei beim Login auf alle aktiven Terminals aus. Aus dieser Erfahrung entstand die Forderung, Passwörter niemals im Klartext zu speichern.

Multics, der Nachfolger von CTSS, führte 1973 erstmals einen Hash-Speicher ein. Robert Morris Senior und Ken Thompson übertrugen das Konzept 1976 ins gerade entstandene Unix und setzten dabei auf eine modifizierte Variante des Data Encryption Standard, die später als crypt(3) bekannt wurde. Die Funktion verschlüsselte einen konstanten Wert mit dem Passwort als Schlüssel, das Ergebnis landete in /etc/passwd.

DES, Salt und die Geburt der Rainbow-Tables

Morris und Thompson erkannten ein Problem: Identische Passwörter ergaben identische Hashes. Ein Angreifer mit einer Liste vorberechneter Hashes konnte tausende Konten gleichzeitig prüfen. Die Lösung erschien 1979 in der bahnbrechenden Arbeit "Password Security: A Case History": ein zwölf Bit langer, zufälliger Salt-Wert, der pro Konto neu erzeugt und mit dem Hash gespeichert wurde. Damit musste ein Angreifer für jedes Konto eine eigene Brute-Force-Schleife starten.

Die DES-Variante hielt sich bis in die 1990er Jahre, geriet dann aber durch wachsende Rechenleistung unter Druck. 1997 zerlegte die EFF mit dem Deep-Crack-Spezialrechner DES in 56 Stunden. Crypt(3) blieb davon zunächst unberührt, weil die Iteration mit 25 Runden den Brute-Force pro Hash verlangsamte, doch die Hash-Länge von nur 64 Bit galt zunehmend als knapp.

MD5 und SHA-1: Schnell, weit verbreitet, ungeeignet

MD5 erschien 1992 als Entwurf von Ronald Rivest und wurde bald für jeden Anwendungsfall zweckentfremdet, in dem ein schneller 128-Bit-Hash gefragt war. Anwendungen speicherten Passwörter zunehmend als plain MD5-Hash ohne Salt, was die Berechnung von Rainbow-Tables wirtschaftlich machte. Schon 2004 demonstrierte Wang Xiaoyun praktische Kollisionen, ein Jahr später knackte ein PlayStation-3-Cluster MD5 in Echtzeit für viele Hash-Eingaben.

SHA-1 folgte 1995 aus dem NIST-Umfeld und ersetzte MD5 dort, wo Sicherheit zumindest auf dem Papier wichtig war. Auch SHA-1 fiel: 2017 publizierten Stevens und Bursztein den SHAttered-Angriff, der eine echte Kollision für 100.000 GPU-Stunden produzierte. Beide Algorithmen sind im Passwort-Kontext seit Jahren nicht mehr empfohlen, tauchen aber bis heute in Datenleaks auf, weil Legacy-Systeme die Hashes nie migriert haben.

Wendepunkte: Datenleaks ändern den Diskurs

Im Dezember 2009 wurde der Spielenetzwerk-Anbieter RockYou Opfer eines SQL-Injection-Angriffs. 32 Millionen Passwörter lagen im Klartext vor und gelangten als rockyou.txt ins Netz. Die Datei wurde zum Standardwörterbuch in Cracking-Tools wie Hashcat und John the Ripper. RockYou markierte den Moment, in dem die Sicherheitsforschung erstmals datengetrieben mit echten Passwort-Verteilungen arbeiten konnte und nicht mehr mit Theorie über Anwenderverhalten spekulieren musste.

2012 traf es LinkedIn: 6,5 Millionen unsalted SHA-1-Hashes leakten zunächst, vier Jahre später tauchten weitere 117 Millionen aus demselben Vorfall auf. Adobe verlor 2013 rund 153 Millionen Datensätze, gespeichert mit 3DES im ECB-Modus, was die Hashes kollisionsanfällig und damit teils umkehrbar machte. Equifax 2017 setzte das Muster fort: 147 Millionen US-Bürger waren betroffen, und obwohl der Vorfall primär Identitätsdaten betraf, ließ er sich durch eine ungepatchte Apache-Struts-Lücke und schwache Admin-Passwörter verstärken.

bcrypt 1999: Hashen wird absichtlich langsam

Niels Provos und David Mazières präsentierten 1999 auf dem USENIX Annual Technical Conference den bcrypt-Algorithmus. Das Verfahren basiert auf der Blowfish-Schlüsselfunktion und führt einen einstellbaren Cost-Faktor ein, der die Iteration exponentiell erhöht. Verdoppelt sich die GPU-Leistung, wird der Faktor um eins erhöht und der Aufwand pro Hash gleicht sich aus. bcrypt war damit das erste Verfahren, das den Begriff "key stretching" konsequent in den Mainstream brachte.

PBKDF2 erschien als Bestandteil von PKCS #5 v2 ebenfalls 1999, ist aber älter konzipiert. Es kombiniert HMAC-SHA mit einer konfigurierbaren Iterationszahl. Im Vergleich zu bcrypt ist PBKDF2 einfacher in Standards zu integrieren, leidet aber an seiner Eigenschaft, dass jede HMAC-Runde auf konstanten Speicheranforderungen läuft, was GPUs und ASICs deutlich besser parallelisieren als bcrypt-Blockoperationen.

scrypt 2009: Speicher statt Rechenzeit

Colin Percival adressierte exakt diesen Speicher-Aspekt 2009 mit scrypt. Sein Verfahren erzwingt einen einstellbaren Speicherverbrauch pro Hash, was den Bau spezialisierter ASICs unwirtschaftlich macht. Eine GPU mit 16 GB VRAM kann zwar tausende bcrypt-Hashes parallel berechnen, scrypt mit 256 MB Speicher pro Hash drückt diese Zahl auf weniger als hundert. Anwendung fand scrypt unter anderem in der Kryptowährung Litecoin, im Passwort-Kontext setzten ihn nur wenige Anbieter konsequent ein.

Argon2: Der PHC-Sieger 2015

Die Password Hashing Competition lief von 2013 bis 2015 unter Beteiligung von 24 Einreichungen aus akademischen Gruppen. Im Juli 2015 erklärten die Juroren Argon2 zum Gewinner. Der Algorithmus stammt von Alex Biryukov, Daniel Dinu und Dmitry Khovratovich an der Universität Luxemburg. Argon2 existiert in drei Varianten: Argon2d optimiert gegen GPU-Angriffe, Argon2i gegen Side-Channel-Attacken, Argon2id kombiniert beide Eigenschaften und gilt als Default-Empfehlung.

Die OWASP Password Storage Cheat Sheet empfiehlt seit 2021 Argon2id mit mindestens 19 MiB Speicher, zwei Iterationen und einer Parallelität von eins als Mindestkonfiguration für serverseitige Passwort-Speicherung. Bcrypt mit Cost-Faktor 10 bleibt akzeptabel, wenn Argon2 nicht verfügbar ist. PBKDF2 mit 600.000 SHA-256-Runden ist die Wahl in Compliance-Umgebungen, in denen FIPS-140-Validierung verpflichtend ist.

Algorithmen-Tabelle

Algorithmus Jahr Designer Schwäche / Stärke Heute empfohlen
crypt(3) DES1976Morris, Thompson56-Bit-Schlüssel, kurzer HashNein
MD51992RivestKollisionen 2004 praktischNein
SHA-11995NSA / NISTKollisionen 2017 praktischNein
bcrypt1999Provos, MazièresCost-Faktor, GPU-resistentAkzeptabel
PBKDF21999RSA LabsFIPS, GPU-friendlyNur in Compliance
scrypt2009PercivalSpeicherhart, weniger AdoptionAkzeptabel
Argon2id2015Biryukov et al.PHC-Sieger, ASIC-resistentJa, Standard

Zeitstrahl der Passwort-Sicherheit

Algorithmen und Wendepunkte 1960 bis 2025 1960 2025 CTSS 1961 crypt(3) 1976 Salt 1979 MD5 1992 SHA-1 1995 bcrypt 1999 RockYou 2009 scrypt 2009 LinkedIn 2012 Argon2 2015 Passkeys 2022

NIST kassiert die Sonderzeichen-Pflicht

Das NIST hatte 2003 in der Special Publication 800-63 die Faustregel geprägt, Passwörter müssten Großbuchstaben, Kleinbuchstaben, Ziffern und Sonderzeichen kombinieren und alle 90 Tage gewechselt werden. Bill Burr, Hauptautor des Dokuments, räumte 2017 in einem Interview mit dem Wall Street Journal ein, dass die Empfehlung "fast alles" falsch gemacht habe. Die Revision 3 der Publikation 800-63B aus dem Jahr 2017 strich die Komplexitätspflicht und verlangte stattdessen eine Mindestlänge von acht Zeichen, ein Verbot häufiger Passwörter sowie keine erzwungenen Wechselintervalle ohne Anlass.

Diese Wende ist weniger Stilfrage als empirisch begründet. Die Analyse großer Leaks zeigt, dass komplexitätsgezwungene Passwörter Muster wie "Sommer2024!" produzieren, die zwar formal die Regel erfüllen, in Wörterbuch-Angriffen aber binnen Sekunden fallen. Eine Passphrase aus fünf zufälligen Wörtern liefert bei deutlich besserer Merkbarkeit ein Vielfaches an Entropie.

Have-I-Been-Pwned als Korrektiv. Troy Hunt startete 2013 die Plattform Have-I-Been-Pwned, um Anwendern zu zeigen, ob ihre E-Mail-Adresse in einem bekannten Leak auftaucht. Die Pwned-Passwords-API hat bisher mehr als 12 Milliarden kompromittierte Hashes indexiert. Sie wird von Browsern, Passwort-Managern und Frameworks wie Spring Security genutzt, um Eingaben in Echtzeit gegen Leak-Datenbanken zu prüfen. Die Existenz dieser Datenquelle hat den Diskurs verschoben: Ein Passwort ist nicht abstrakt schwach oder stark, sondern entweder bereits geleakt oder noch nicht.

Passkeys: Die Post-Passwort-Ära beginnt

Die FIDO Alliance startete 2013 mit dem Ziel, Passwörter durch hardwaregebundene Schlüsselpaare abzulösen. Der erste Wurf U2F als Zwei-Faktor-Token, der zweite WebAuthn 2019 als Browser-Standard. Der dritte Schritt sind Passkeys: Apple stellte sie 2022 auf der WWDC vor, Google folgte 2023, Microsoft im selben Jahr. Ein Passkey ist ein asymmetrisches Schlüsselpaar, dessen privater Teil das Gerät niemals verlässt. Die Authentifizierung läuft über eine Challenge-Response-Signatur, ein Phishing-Angriff scheitert daran, dass das Schlüsselpaar an die Origin gebunden ist.

Passwort-Manager haben Passkeys schnell adoptiert, weil sie das Cross-Device-Problem lösen: Apple synchronisiert Passkeys über iCloud Keychain, 1Password und Bitwarden über ihre eigenen Tresore. Damit verschiebt sich die Rolle des Passwort-Managers vom Tresor für Geheimworte zum universellen Authentifikator.

Die parallele Entwicklung der Zwei-Faktor-Authentifizierung

Während Hash-Algorithmen den Server-seitigen Schutz prägten, entwickelte sich auf der Client-Seite die Zwei-Faktor-Authentifizierung. Die ersten Hardware-Token erschienen 1986 mit dem RSA SecurID, einem proprietären Time-based-One-Time-Password-Verfahren. Die Internet Engineering Task Force standardisierte 2005 mit RFC 4226 das HMAC-based One-Time Password und 2011 mit RFC 6238 das Time-based Pendant, was die Grundlage für heute übliche Apps wie Google Authenticator, Authy und Aegis legte.

SMS-basierte Codes dagegen verlieren an Empfehlung. Das NIST stufte sie 2016 als "deprecated" ein, weil SS7-Angriffe und SIM-Swapping reale Bedrohungsszenarien sind. Der Twitter-Hack im Juli 2020, bei dem Angreifer durch Social Engineering interne Tools übernahmen, demonstrierte, wie wenig SMS-MFA bei gezielten Angriffen schützt. FIDO2-Hardware-Token wie der YubiKey gelten seitdem als Goldstandard, sind in regulierten Branchen wie Banking aber wegen zentraler Bereitstellungslogistik nur langsam verbreitet.

Wie Hashcat und John the Ripper den Diskurs prägten

Cracking-Tools sind zugleich Angriffs- und Forschungswerkzeug. John the Ripper erschien 1996 als Open-Source-Antwort auf das Aufkommen schwacher Unix-Hashes. Hashcat folgte 2009 mit GPU-Beschleunigung und ist seitdem die Referenz für Benchmarks. Beide Tools liefern den empirischen Beleg, dass der theoretische Suchraum eines Passworts wenig sagt, solange Wörterbücher und Mutationsregeln den realen Aufwand drastisch senken. Die Hashcat-Foren publizieren seit 2012 Benchmark-Tabellen für jede neue GPU-Generation, was Sicherheitsverantwortlichen erlaubt, ihre Hash-Parameter periodisch nachzuschärfen.

Die Veröffentlichung dieser Werte wirkt zweischneidig. Einerseits hilft sie Verteidigern bei der Kalibrierung, andererseits erleichtert sie auch Angreifern den Vergleich verschiedener Algorithmen. Die Sicherheitsforschung argumentiert mit Kerckhoffs' Prinzip aus dem 19. Jahrhundert: Sicherheit darf nicht auf der Geheimhaltung des Verfahrens beruhen, sondern auf der Geheimhaltung des Schlüssels. Genau aus diesem Grund werden Cracking-Benchmarks konsequent öffentlich diskutiert.

Anekdoten am Rande: Der RSA-Hack 2011 und die Folgen

Im März 2011 brachen Angreifer in das Netzwerk der RSA Security ein und entwendeten Seed-Werte für die SecurID-Token-Familie. Die Konsequenz: Die hardware-basierte Zwei-Faktor-Authentifizierung von rund 40 Millionen Tokens war kompromittiert, weil die Angreifer aus den Seeds gültige Codes berechnen konnten. Der Vorfall führte zu einer Welle von Folge-Einbrüchen, etwa bei Lockheed Martin und L-3 Communications. RSA tauschte fast alle Tokens auf eigene Kosten aus, schätzungsweise 50 Millionen US-Dollar Aufwand. Branchenmedien wie Wired und Ars Technica analysierten den Vorgang als Wendepunkt für die kommerzielle Akzeptanz cloud-gestützter MFA-Lösungen, die in den Folgejahren rapide an Marktanteil gewannen.

Die langfristige Lehre des RSA-Vorfalls: Auch hardware-basierte Zwei-Faktor-Verfahren sind nur so sicher wie ihre zentrale Bereitstellungslogistik. FIDO2-Token nach dem WebAuthn-Standard adressieren genau diese Schwäche, weil der private Schlüssel das Token niemals verlässt und kein zentral verwalteter Seed existiert. Ein Diebstahl beim Token-Hersteller hätte heute keine vergleichbaren Folgen.

Stand der Technik

Argon2id mit OWASP-Parametern bildet 2026 den Server-seitigen Stand der Technik. Auf der Anwender-Seite empfiehlt sich eine lange Passphrase als Master-Passwort des Managers, kombiniert mit einer hardwaregebundenen Zwei-Faktor-Komponente, idealerweise einem FIDO2-Token. Für Dienste, die Passkeys anbieten, gilt deren Aktivierung als sinnvolle Anschluss-Investition. Der Übergang verläuft schleichend: Erst wenn die Mehrheit der Konten passkey-fähig ist, wird das Passwort zur Ausnahme. Die Geschichte der vergangenen 60 Jahre zeigt aber, dass jede Generation von Verfahren früher oder später durch Rechenleistung oder strukturelle Schwächen überholt wird. Dass Argon2id für die nächsten 15 Jahre genügt, gilt als wahrscheinlich, nicht als sicher.

Häufige Fragen

Warum sind MD5-Hashes in Datenbanken bis heute ein Problem?

MD5 wurde 1992 entworfen und sollte nie als Passwort-Hash dienen, fand aber in unzähligen PHP-Anwendungen der frühen 2000er Verbreitung. Selbst gesalzene MD5-Hashes lassen sich auf moderner Hardware mit über 100 Milliarden Versuchen pro Sekunde auf einer einzigen GPU prüfen. Wenn ein Anbieter heute MD5-Hashes verliert, sind nahezu alle Passwörter unter zehn Zeichen binnen Stunden geknackt. Der einzig saubere Migrationspfad besteht darin, beim nächsten Login des Anwenders den eingegebenen Klartext mit Argon2id neu zu hashen und die alte Spalte zu löschen.

Reicht bcrypt heute noch oder muss man auf Argon2id wechseln?

bcrypt mit einem Cost-Faktor von 12 oder höher gilt nach OWASP weiterhin als sicher und wird in produktiven Anwendungen breit eingesetzt. Argon2id bietet darüber hinaus Schutz gegen ASIC- und FPGA-Angreifer, weil der einstellbare Speicherbedarf solche Spezialhardware unwirtschaftlich macht. Für Neuentwicklungen ist Argon2id die erste Wahl, bestehende bcrypt-Installationen müssen nicht zwingend migriert werden, sofern der Cost-Faktor regelmäßig an den Stand der GPU-Leistung angepasst wird.

Was war so besonders am RockYou-Leak von 2009?

RockYou war der erste große Vorfall, bei dem Klartext-Passwörter unverschlüsselt in einer öffentlich zugänglichen Datei landeten. Sicherheitsforscher konnten erstmals empirisch untersuchen, wie Anwender Passwörter wirklich wählen. Die Auswertung zeigte, dass etwa 30 Prozent aller Konten weniger als 1.000 verschiedene Passwörter teilten und dass Muster wie "123456" oder "password" zweistellige Prozentsätze erreichten. Die Datei rockyou.txt ist seitdem fester Bestandteil aller Cracking-Frameworks und prägt bis heute die Wörterbuch-Angriffe.

Werden Passkeys Passwörter komplett ablösen?

Auf absehbare Zeit nicht vollständig. Passkeys lösen die häufigsten Probleme: Phishing, Credential-Stuffing und schwache Geheimworte. Sie setzen aber moderne Endgeräte und Anbieter-Support voraus. Legacy-Systeme, regulierte Branchen mit Hardware-Token-Pflicht und Konten ohne FIDO2-Implementierung werden Passwörter über Jahre weiterführen. Realistisch ist ein hybrider Zustand bis 2030, in dem Passkeys den Standard für neue Konten bilden, Passwörter für Altsysteme aber bestehen bleiben. Passwort-Manager werden in dieser Phase zur zentralen Drehscheibe für beide Authentifizierungsformen.

Wie kam NIST dazu, die Komplexitätsregeln zurückzunehmen?

Die ursprüngliche Empfehlung von 2003 stammte aus einer Phase, in der empirische Daten zu Passwort-Wahl praktisch nicht existierten. Erst die Massenleaks ab 2009, allen voran RockYou, lieferten die Datenbasis. Forscher der Carnegie Mellon University und des Bundesamts für Sicherheit zeigten in mehreren Studien, dass Komplexitätsregeln zu vorhersagbaren Ersetzungsmustern führen, etwa "a" durch "@" oder das Anhängen einer "1!". Die NIST-Revision 2017 zog daraus die Konsequenz, weniger Regeln vorzuschreiben und stattdessen die Mindestlänge anzuheben sowie Leak-Datenbanken als Sperrliste zu integrieren.

Verwendete Quellen

Stand: 2026-05-04. Korrektur-Hinweise an info@akara-solutions.de oder über die Methodik-Seite.