Kostenloser Massen-Passwortgenerator

Erzeugen Sie mehrere starke Passwörter auf einmal. Passen Sie Anzahl, Länge und Zeichenoptionen an und laden Sie sie als Textdatei herunter.

Passwörter werden lokal auf Ihrem Gerät erzeugt
Klicken Sie auf „Passwörter erzeugen", um zu beginnen

    Massenhafte Passworterzeugung

    Dieses Tool erzeugt mehrere kryptografisch starke Passwörter in einem Vorgang. Ideal für Passwortlisten beim Onboarding eines Teams, die Massenanlage von Konten oder die Pflege sicherer Passwortbestände. Jedes Passwort wird mit dem im Browser eingebauten Zufallszahlengenerator erzeugt.

    Stufen der Passwortstärke

    Häufige Fragen

    Sind diese Passwörter wirklich zufällig?

    Ja. Die Passwörter werden mit window.crypto.getRandomValues() erzeugt, das kryptografisch sichere Zufallswerte für sicherheitsrelevante Zwecke liefert.

    Kann ich mehr als 100 Passwörter erzeugen?

    Das Tool begrenzt die Erzeugung auf 100 pro Durchgang, um den Browser nicht zu verlangsamen. Erzeugen Sie bei Bedarf mehrere Sätze nacheinander.

    Wie soll ich die heruntergeladene Datei aufbewahren?

    Bewahren Sie die .txt-Datei an einem sicheren, idealerweise verschlüsselten Ort auf. Niemals in eine Versionsverwaltung committen oder über unsichere Kanäle teilen. Löschen Sie sie nach der Verteilung an die Nutzer.

    Woher gute Zufallszahlen kommen

    Ein Computer ist von Natur aus deterministisch. Bei gleichen Eingaben und gleichem Code erzeugt er jedes Mal die gleichen Ausgaben. Genau diese Eigenschaft wünschen Sie sich von einer CPU, die eine Tabellenkalkulation ausführt, und genau diese Eigenschaft wollen Sie bei einem Passwortgenerator nicht. Wenn ein Angreifer die Folge der Werte reproduzieren kann, die der Generator ausgegeben hat, kann er jedes Passwort reproduzieren, das dieser je ausgegeben hat.

    Deshalb sammelt der Generator „Entropie“ (unvorhersehbares physisches Signal von außerhalb des Programms) und nutzt sie, um einen Algorithmus namens CSPRNG (kryptografisch sicherer Pseudozufallszahlengenerator) zu initialisieren. Das „Pseudo“ ist ehrlich: Die Bits werden von einem Algorithmus erzeugt, nicht von der Physik. „Kryptografisch sicher“ bedeutet, dass selbst ein Angreifer, der einen langen Lauf vergangener Ausgaben sieht, das nächste Byte nicht besser als der Zufall vorhersagen kann. Theodore Ts'o implementierte 1994 /dev/random im Linux-Kernel, und macOS, die BSDs, Solaris und Windows (mit BCryptGenRandom) übernahmen allesamt gleichwertige Schnittstellen. Im Inneren mischen diese jede plausible Quelle physischen Jitters (Festplatten-Suchzeiten, Ankunft von Netzwerkpaketen, Tastatur- und Mauseingaben, Hardware-Interrupts, RDRAND auf Intel-CPUs, die es haben) über einen kryptografischen Hash und initialisieren sich dann fortlaufend neu.

    Im Browser stellt die W3C Web Cryptography API dies über window.crypto.getRandomValues(typedArray) bereit: Übergeben Sie ihr ein typisiertes Array, und der Browser füllt es mit kryptografisch starken Zufallsbytes. Das Maximum pro Aufruf sind 65.536 Byte (dieses Tool bleibt deutlich darunter). Die API wird seit Juli 2015 grundlegend in Chrome, Firefox, Safari und Edge unterstützt: Es gibt keine realistische Möglichkeit, dass ein Nutzer mit einem Browser auf diesem Tool landet, dem sie fehlt.

    Passwort-Entropie, die eigentliche Mathematik

    Passwort-„Stärke“ im formalen kryptografischen Sinne wird in Entropie-Bits gemessen. Die Standardformel für ein zufällig erzeugtes Passwort lautet:

    Entropie = L × log₂(R)

    wobei L die Länge in Zeichen und R die Größe des Zeichenvorrats ist. Entropie pro Zeichen nach Zeichensatz:

    Die Zahl 94 lohnt sich festzuhalten: Die ASCII-Codes 32 bis 126 sind die druckbaren Zeichen (insgesamt 95); ohne das Leerzeichen bleiben 94 sichtbare Nicht-Leerzeichen-Glyphen (26 Klein- + 26 Großbuchstaben + 10 Ziffern + 32 Satz-/Sonderzeichen). Setzt man konkrete Zahlen in die Formel ein:

    Die kryptografische Gemeinschaft hat sich auf drei Schwellen geeinigt: 80 Bit als absolutes Minimum (NISTs empfohlene Untergrenze bis 2014), erreicht bei ~13 Zeichen mit dem vollen 94-Zeichen-Satz; 100 Bit, von ANSSI (dem französischen Pendant zur NSA) für Passwörter gefordert, die Verschlüsselungssysteme schützen, erreicht bei ~16 Zeichen; und 128 Bit, was der Stärke des symmetrischen Schlüssels von AES-128 entspricht, empfohlen für Master-Passwörter von Tresoren, erreicht bei ~20 Zeichen.

    Der große Vorbehalt: Diese Mathematik gilt nur für zufällige Passwörter. Wenn ein Mensch das Passwort gewählt hat, ist die effektive Entropie viel, viel niedriger. Der Angreifer zählt nicht R^L Zeichenketten alphabetisch durch, sondern lässt ein Rateprogramm laufen, das mit geleakten Passwortlisten, Wörterbuchwörtern, gängigen Ersetzungen (a→@, o→0, s→$), Tastaturmustern und statistischen Modellen davon, wie Menschen einprägsame Zeichenketten bilden, gefüttert wird. Joseph Bonneaus Studie von 2012 über ein anonymisiertes Korpus von 70 Millionen Yahoo-Passwörtern (IEEE Symposium on Security and Privacy) ergab, dass von Nutzern gewählte Passwörter „weniger als 10 Bit Sicherheit gegen einen Online-Trawling-Angriff und nur etwa 20 Bit gegen einen optimalen Offline-Wörterbuchangriff“ bieten. Zwanzig Bit sind eine Million Versuche. Eine moderne GPU schafft das in Mikrosekunden.

    NIST SP 800-63B, was sich 2017 und erneut 2025 änderte

    Etwa dreißig Jahre lang ging die nordamerikanische Sicherheitspolitik zu Passwörtern auf eine NIST-Veröffentlichung von 1985 zurück, die erzwungene regelmäßige Wechsel, gemischte Zeichenklassen und kurze Mindestlängen empfahl. Bill Burr, Autor der Folgepublikation von 2003, die die Regel „Großbuchstabe + Kleinbuchstabe + Ziffer + Symbol, alle 90 Tage ändern“ festschrieb, widerrief sie 2017 öffentlich und sagte dem Wall Street Journal, dass er „vieles von dem, was ich getan habe, heute bereue“. NIST formalisierte die Kehrtwende im selben Jahr.

    NIST SP 800-63B Rev 3 (Juni 2017) brachte zwei generationsprägende Änderungen. Abschnitt 5.1.1.2 lautet: „Prüfer SOLLTEN NICHT verlangen, dass gespeicherte Geheimnisse willkürlich (z. B. regelmäßig) geändert werden“, weil erzwungene Wechsel dazu führen, dass Nutzer schwächere, vorhersehbarere Passwörter wählen. Derselbe Abschnitt: „Prüfer SOLLTEN für gespeicherte Geheimnisse KEINE weiteren Zusammensetzungsregeln auferlegen (z. B. die Mischung verschiedener Zeichentypen verlangen)“, weil das Erzwingen einer Ziffer und eines Symbols Nutzer eher zu Password1! als zu einer längeren Passphrase drängt. Rev 3 legte die vom Teilnehmer gewählte Mindestlänge auf 8 Zeichen fest, verlangte, dass Prüfer bis zu 64 akzeptieren, schrieb die Prüfung neuer Passwörter gegen Sperrlisten aus Datenlecks vor und verlangte ausdrücklich, dass Passwortmanager und das Einfügen aus der Zwischenablage erlaubt sein müssen.

    NIST SP 800-63B Rev 4 (final am 31. Juli 2025) verschärfte die Latte: Einfaktor-Passwörter erfordern jetzt eine Mindestlänge von 15 Zeichen („Prüfer und CSPs MÜSSEN verlangen, dass Passwörter, die als Einfaktor-Authentifizierungsmechanismus verwendet werden, eine Mindestlänge von 15 Zeichen haben“). Mehrfaktor-Passwörter bleiben bei 8 Zeichen, weil der zweite Faktor das Sicherheitsgewicht trägt. Zusammensetzungsregeln sind weiterhin verboten, und die Formulierung wechselte von Rev 3 „SOLLTEN NICHT“ zu Rev 4 „DÜRFEN NICHT“, womit aus einer Empfehlung eine harte Anforderung wird. Von Wechseln wird weiterhin abgeraten, sofern es keine Hinweise auf eine Kompromittierung gibt.

    Das Absolutool-Tool erzeugt standardmäßig 16 Zeichen mit allen vier Zeichenklassen, was rund 104 Bit Entropie ergibt und sowohl die 15-Zeichen-Mindestlänge von Rev 4 als auch die 80-Bit-Schwelle der symmetrischen Äquivalenz bequem überschreitet. Das Maximum des Tools von 128 Zeichen liegt bei genau dem Doppelten der Höchstlänge, die NIST den Prüfern zu akzeptieren vorschreibt, es gibt keinen realistischen Fall, in dem ein erzeugtes Passwort für einen Server zu lang wäre.

    RockYou, die Katastrophe, die 2026 noch immer nachwirkt

    Im Dezember 2009 wurde die Social-Games-Firma RockYou über eine lehrbuchmäßige SQL-Injection kompromittiert. Das Leck legte über 32 Millionen Nutzerkonten offen, einschließlich der Passwörter dieser Konten im Klartext: RockYou hatte sie unverschlüsselt gespeichert. Die Passwortrichtlinie des Unternehmens verlangte damals nur fünf Zeichen und verbot Sonderzeichen, was die Schwachstelle noch verschärft hatte.

    Die kompromittierte Datei, bald rockyou.txt genannt, wurde offen veröffentlicht und bleibt die meistreferenzierte Passwort-Wortliste der Welt. Sie ist für Penetrationstester standardmäßig in Kali Linux enthalten; jedes Wörterbuchangriffs-Werkzeug der Welt prüft gegen sie; kommerzielle Credential-Stuffing-Dienste pflegen sie als Grundlinie. Sechzehn Jahre später erwischen Angreifer noch immer aktive Konten mit Passwörtern, die zuerst im Leck von 2009 auftauchten. Die verbreiteten Lehren: Server sollten niemals Klartext-Passwörter sehen (dieses Tool erzeugt clientseitig, sodass der Server sie überhaupt nie sieht); gespeicherte Passwörter sollten mit einer langsamen, gesalzenen, speicherintensiven Funktion wie Argon2id oder bcrypt gehasht werden, nicht mit einem schnellen Hash wie MD5 oder ungesalzenem SHA-1; eindeutige Passwörter pro Website sind die einzige Verteidigung gegen den Replay-Angriff mit gestohlenen Zugangsdaten, der das vergangene Jahrzehnt der Datenlecks beherrscht hat.

    Have I Been Pwned und das Datenleck-Korpus

    Have I Been Pwned (HIBP), betrieben von Microsoft Regional Director Troy Hunt, ist zur maßgeblichen Standardquelle für die Frage „Ist dieses Passwort in einem Datenleck aufgetaucht?“ geworden. Hunt startete HIBP 2013 als durchsuchbaren Index kompromittierter E-Mail-Adressen; später fügte er das Korpus Pwned Passwords hinzu, eine herunterladbare Liste jedes in einem öffentlichen Leck gesehenen Passworts, indexiert nach SHA-1-Hash. Pwned Passwords V2 startete am 22. Februar 2018 und führte die k-Anonymitäts-API des Datensatzes ein (mit Cloudflare gebaut): Ein Client sendet nur die ersten fünf Zeichen des SHA-1-Hashs; der Server gibt jeden vollständigen Hash zurück, der mit diesen fünf Zeichen beginnt, samt der Anzahl der Beobachtungen; der Client vergleicht lokal. Das Passwort (und selbst sein vollständiger Hash) verlässt nie das Gerät des Nutzers.

    Für einen Massengenerator ist das in zweifacher Hinsicht relevant. Ein Passwort, das bereits in HIBP steht, ist per Definition kein nützliches neues Passwort, es ist das Erste, was jeder Credential-Stuffing-Angreifer ausprobiert. Und weil dieses Tool mit voller CSPRNG-Zufälligkeit aus einem 94-Zeichen-Alphabet erzeugt, ist die Wahrscheinlichkeit, dass ein frisch erzeugtes 16-Zeichen-Passwort bereits in HIBP steht, praktisch null. (Die Gesamtzahl der 16-Zeichen-ASCII-Symbol-Passwörter beträgt 94^16 ≈ 3,7 × 10³¹; HIBP enthält rund 10⁹ bekannte Passwörter; Kollisionswahrscheinlichkeit ≈ 10⁻²².)

    Was „X Bit Entropie“ in echter Knackzeit bedeutet

    Die Zahl, die Entropie-Bits konkrete Bedeutung verleiht, ist „Wie lange bräuchte ein moderner Angreifer?“, und die Antwort hängt ganz vom Hash-Algorithmus ab. Der von der Gemeinschaft veröffentlichte Benchmark für hashcat v6.2.6 auf einer einzelnen Nvidia RTX 4090 verzeichnet etwa 300 GH/s für NTLM-Hashes (Microsofts alter Windows-Hash) und 200 kH/s für bcrypt. Der Abstand von vier Größenordnungen zwischen diesen beiden ist die tragende Tatsache: NTLM wurde auf Geschwindigkeit ausgelegt, bcrypt wurde darauf ausgelegt, langsam zu sein.

    Die viel zitierten Passworttabellen von Hive Systems verwandeln die Benchmarks in Knackzeit-Werte. Die Version 2025, gegen MD5-Hashes berechnet (fast so schnell wie NTLM), gibt ~59 Minuten auf einer RTX 4090 an, um ein 8-Zeichen-Passwort aus dem vollen Zeichensatz per Brute Force zu knacken. Dasselbe 8-Zeichen-Passwort gegen einen bcrypt-Hash braucht ~99 Jahre auf derselben Hardware. Dieser Abstand von vier Größenordnungen ist der Unterschied zwischen „gestern geleakt, bis zum Mittagessen geknackt“ und „gestern geleakt, wird Sie überleben“.

    Der Endnutzer kontrolliert die Passwortlänge und den Zeichensatz. Er kontrolliert nicht den Hash-Algorithmus, den der Server zur Speicherung verwendet. Die meisten gut betriebenen modernen Dienste verwenden bcrypt, scrypt oder Argon2id, allesamt bewusst langsam. Ältere und kompromittierte Dienste verwendeten häufig MD5 oder ungesalzenes SHA-1, weshalb alte Datenleck-Korpora mit den oben genannten Geschwindigkeiten geknackt werden können. Für ein von diesem Tool erzeugtes Passwort gilt: Ein 16-Zeichen-Zufallspasswort ist gegen bcrypt im Grunde für immer sicher und gegen MD5 vorerst einigermaßen sicher; ein 20-Zeichen-Passwort ist gegen beides übertrieben. Es gibt kein realistisches Bedrohungsmodell, in dem 20+ Zeichen CSPRNG-Ausgabe das schwache Glied wären.

    FIDO2, WebAuthn und der Übergang zu Passkeys

    Die langlebigste Vorhersage der Sicherheitsbranche ist, dass Passwörter verschwinden. Seit 2019 gibt es endlich einen glaubwürdigen Ersatz: Passkeys, der Verbraucher-Marketingname für Zugangsdaten, die nach den FIDO2-/WebAuthn-Standards ausgestellt werden. WebAuthn Level 1 wurde am 4. März 2019 eine W3C-Empfehlung; Level 2 folgte am 8. April 2021. Das kryptografische Modell ist asymmetrisch: Wenn sich ein Nutzer registriert, erzeugt der Authentifikator ein öffentliches/privates Schlüsselpaar, sendet den öffentlichen Schlüssel an den Server und speichert den privaten Schlüssel in sicherer lokaler Hardware. Die Authentifizierung verwendet ein mit dem privaten Schlüssel signiertes Challenge-Response-Verfahren. Der Server sieht das Geheimnis nie, was bedeutet, dass ein serverseitiges Leck keine Anmeldedaten offenlegen kann.

    Die Einführungen der großen Plattformen erfolgten im Gleichschritt durch die Jahre 2022-2023: Apple führte Passkeys auf der WWDC am 6. Juni 2022 vor und lieferte sie im September 2022 öffentlich mit iOS 16, iPadOS 16 und macOS Ventura aus, Synchronisierung über den Ende-zu-Ende-verschlüsselten iCloud-Schlüsselbund. Google kündigte am 12. Oktober 2022 die Passkey-Unterstützung für Android und Chrome an; stabile Chrome-Unterstützung kam im Dezember 2022 mit Chrome 108, Synchronisierung über den Google Passwortmanager. Microsoft kündigte am 21. September 2023 die Passkey-Verwaltung für Windows 11 an, integriert mit Windows Hello.

    Passkeys lösen die schmerzhaftesten Arten von Passwortversagen (Phishing, Credential Stuffing, Server-Leck), haben Passwörter aber nicht beseitigt, weil: viele Websites und die meisten Altsysteme weiterhin eines verlangen; Passkeys an ein Gerät oder ein Synchronisierungs-Ökosystem gebunden sind (Nutzer ohne Apple-, Google- oder Microsoft-Konto brauchen eine Alternative); kopflose Systeme (IoT-Geräte, serverseitige Dienstkonten, Massen-Onboarding-Szenarien) sich beim Registrierungsschritt nicht auf einen biometrischen Authentifikator verlassen können; und viele Unternehmens-Passwortrichtlinien, Bankensysteme und Behördenportale weiterhin Passwörter vorschreiben. Die Massen-Passworterzeugung fällt genau in die zweite und dritte Kategorie: Ein Systemadministrator, der 50 neue Konten bereitstellt, kann nicht jeden künftigen Nutzer bitten, einen Passkey einzurichten, bevor das Konto existiert.

    Warum gerade die clientseitige Erzeugung wichtig ist

    Stellen Sie sich ein Konkurrenz-Tool vor, das die Anfrage des Nutzers per POST an einen Server schickt, der Server den Zufallsgenerator ausführt und die Liste als JSON zurückgibt. Selbst wenn alles wie beworben funktioniert, können die folgenden Parteien die erzeugten Passwörter im Klartext sehen: der Prozessspeicher des Servers, während die Anfrage bearbeitet wird; die Anfrageprotokolle des Servers (wenn die Protokollierung naiv ist); jeder APM- oder Fehlerverfolgungsdienst, an den der Server angeschlossen ist; der TLS-terminierende Reverse-Proxy (Cloudflare, AWS-Lastverteiler, nginx); jedes auf dem Server laufende Debugging-Werkzeug; jeder künftige Angreifer, der Zugriff auf eines dieser Protokolle erlangt. Das RockYou-Modell mit allen seinen Folgen gilt.

    Wenn die Erzeugung über window.crypto.getRandomValues() im Browser des Nutzers geschieht, gilt nichts davon. Die Bytes werden im Browserprozess auf dem Rechner des Nutzers erzeugt, durch Code, den der Nutzer prüfen kann (der Seitenquelltext ist einsehbar). Sie überqueren nie das Netzwerk. Absolutools Server sieht sie nie, protokolliert sie nie und kann sie in einem künftigen Leck nicht preisgeben, weil er sie nie hatte. Die einzigen Instanzen, die die erzeugten Passwörter sehen, sind der Nutzer, jeder mit Zugriff auf die Browsersitzung des Nutzers (in der Regel nur der Nutzer) und alle auf der Seite laufenden Browser-Erweiterungen. Das ist dasselbe Sicherheitsmodell wie der lokale Generator eines Passwortmanagers und stärker als das Modell jedes Webdienstes, der erzeugte Passwörter von einem Server zurückgibt.

    Mirai 2016, das Negativbeispiel für IoT-Standardwerte

    Das lehrbuchmäßige Negativbeispiel für „verwenden wir einfach dasselbe Standardpasswort auf jedem Gerät“ ist das Mirai-Botnetz. Mirai nutzte eine fest codierte Liste von etwa 62 herstellerseitigen Standard-Benutzername/Passwort-Kombinationen (admin/admin, root/root, root/xc3511, root/vizxv), um Ende 2016 Hunderttausende von IP-Kameras, DVRs und Heimroutern zu infizieren, und setzte sie dann am 21. Oktober 2016 ein, um den großen DNS-Anbieter Dyn lahmzulegen und kurzzeitig Twitter, Reddit, Netflix und GitHub auszuschalten. Ein Massen-Passwortgenerator ist genau das richtige Mittel für die Alternative: einen eindeutigen starken Standardwert pro Gerät am Fließband erzeugen, ihn auf einen Aufkleber drucken und in der Schachtel mitliefern.

    Weitere Fragen

    Warum empfiehlt NIST Länge statt Komplexität?

    Weil das Erzwingen von Komplexität (eine Ziffer, ein Symbol, ein Großbuchstabe) Nutzer in vorhersehbare Muster drängt, die der Angreifer bereits modelliert hat. Password1! hat mathematisch mehr Entropie als password, aber in der Praxis beginnt die Wortliste jedes Angreifers genau dort. Eine 20 Zeichen lange, rein kleingeschriebene Zeichenkette aus einem CSPRNG hat ~94 Bit Entropie und kann von keiner Wortliste erraten werden, weil sie zu keiner Wortliste passt. NIST SP 800-63B Rev 4 (Juli 2025) macht das Verbot von Zusammensetzungsregeln zu einer harten DÜRFEN-NICHT-Anforderung.

    Sollte ich stattdessen Passphrasen verwenden?

    Für Passwörter, die Sie sich merken müssen, ja, das war das Argument von xkcd #936 (10. August 2011). Die Diceware-Methode (Arnold Reinhold, 1995) liefert 12,9 Bit pro Wort aus einer Liste von 7.776 Wörtern; sechs Wörter ≈ 77,5 Bit sind die moderne Empfehlung. Die EFF veröffentlichte im Juli 2016 aktualisierte, Diceware-kompatible Wortlisten. Aber für den Massenbereitstellungs-Anwendungsfall, dem dieses Tool dient (temporäre Token, die bei der ersten Anmeldung geändert werden), ist zufälliges ASCII das richtige Mittel, weil der Nutzer es nie eintippen muss.

    Ist das Ausschließen mehrdeutiger Zeichen ein Sicherheitskompromiss?

    Ja, technisch gesehen verkleinert das Weglassen von i, l, 1, L, O, 0, o das Alphabet von 94 auf 87 und senkt die Entropie pro Zeichen von 6,55 Bit auf 6,44 Bit. Bei 16 Zeichen sind das 103,0 Bit statt 104,8 Bit, völlig unerheblich. Der Kompromiss zahlt sich aus, wenn Menschen das Passwort laut vorlesen oder von einem ausgedruckten Blatt abschreiben müssen, was genau das Massenverteilungs-Szenario ist, dem dieses Tool dient.

    Was ist der sicherste Weg, eine erzeugte Liste zu verteilen?

    Behandeln Sie die erzeugte Liste als einmaliges Artefakt. Verteilen Sie sie über einen vorab vereinbarten Kanal (verschlüsselte E-Mail mit PGP/GPG, sichere Dateiübertragung, Import in einen Passwortmanager, persönliche Übergabe per Datenträger in Hochrisikokontexten). Konfigurieren Sie die Systeme so, dass sie bei der ersten Anmeldung eine Passwortänderung verlangen. Löschen Sie die Datei nach der Verteilung. Versenden Sie niemals Klartextlisten per E-Mail, übergeben Sie sie niemals an die Versionsverwaltung, fügen Sie sie niemals in einen Chat ein. Die erzeugten Passwörter sind als Einmal-Token gedacht, der Wert liegt in der kryptografischen Zufälligkeit für die erste Übergabe, nicht in der langfristigen Aufbewahrung.

    Verwandte Tools

    Passwort-Generator

    Erzeugen Sie ein einzelnes starkes Zufallspasswort.

    Base64-Encoder

    Base64 sofort kodieren und dekodieren.

    Zufallszeichenketten-Generator

    Erzeugen Sie zufällige Zeichenketten mit eigenen Mustern.