Passworttechnik
Woher kommt die Zufälligkeit von Passwörtern?
12. Mai 2026 · 6 Min. Lesezeit
Passwort-Generatoren wirken simpel: Klick, Geheimnis. Entscheidend ist, was vor der Anzeige passiert. Woher kommt die Zufälligkeit? Wie werden Bytes zu Zeichen oder Wörtern? Was kann ein Nutzer tun, der zusätzliche Zufälligkeit einbringen will?
Der Artikel beschreibt die Quelle der Zufälligkeit in browserbasierten Generatoren, den richtigen Umgang mit Entropie und wie eine optionale Interaktion (z. B. ein kleines Tastaturspiel) mit der kryptografischen Quelle des Browsers kombiniert werden kann.
Die Kurzantwort
Auf passwords.lu entsteht das Passwort im Browser. Die Seite holt kryptografisch starke Zufallsbytes, wandelt sie in Zeichen oder Wörter um und zeigt das Ergebnis lokal an.
Damit gibt es zwei getrennte Sicherheitseigenschaften: Zufälligkeit erschwert Raten, und lokale Erzeugung vermeidet, das Geheimnis durch die Anwendungsinfrastruktur zu schicken.
Warum lokale Erzeugung anders ist
Frühe Web-Generatoren erzeugten das Geheimnis oft auf dem Server und zeigten es dann an. Das kann ehrlich umgesetzt sein, erzeugt aber ein vermeidbares Vertrauensproblem.
Der Nutzer muss glauben, dass der Server das Passwort nicht protokolliert, zwischenspeichert, über Analytics preisgibt oder über die Infrastruktur leckt. Browser-native Erzeugung dreht das um: Der Server liefert Code, das Geheimnis entsteht auf dem Gerät.
Für einen Passwort-Generator ist das das sauberere Datenschutzmodell. Je weniger Systeme das Geheimnis je sehen, desto weniger Angriffsfläche für Fehlbedienung.
Warum Zufälligkeit wichtig ist
Menschen sind schlechte Zufallsgeneratoren: Daten, Namen, Tastaturmuster, Lieblingswörter, Formen, kleine Variationen von Gewohntem.
Angreifer wissen das. Cracking-Tools probieren nicht brute-force aaa–zzz, sondern Leaks, Wörterbücher, Ersetzungen, Tastaturmuster, Jahre, typische Kombinationen.
Ein sicherer Generator verlangt keine Kreativität. Er zieht unvorhersehbare Werte aus einer kryptografisch sicheren Zufallsquelle und bildet sie auf Zeichen oder Wörter ab — ohne vermeidbaren Bias.
Was Entropie hier bedeutet
Bei Passwörtern misst Entropie, wie viele Möglichkeiten ein Angreifer in Betracht ziehen muss — meist in Bits.
Ein Bit: zwei gleich wahrscheinliche Fälle; zwei Bits: vier; zehn Bits: 1.024. Jedes weitere Bit verdoppelt den Suchraum — schneller, als es sich anfühlt.
Wird das Passwort gleichverteilt aus einer endlichen Menge gezogen, ist die Entropie log2(Anzahl der Möglichkeiten). Ein zufälliges Zeichen aus 64 Symbolen liefert 6 Bits (2^6 = 64).
Darum zählt die Methode: Stärke kommt nicht daher, dass etwas kompliziert aussieht, sondern aus großer, für Angreifer unvorhersehbarer Auswahl.
Ein 16-stelliges Passwort aus 64 Symbolen hat etwa 96 Bits Entropie. Eine 5-Wort-Passphrase im Diceware-Stil aus 7.776 Wörtern etwa 64,6 Bits (log2(7.776) ≈ 12,9 Bits pro Wort).
Passphrases sind oft angenehmer zu merken, aber länger sichtbar heißt nicht automatisch stärker als eine kürzere echte Zufallszeichenkette. Entscheidend sind die zufälligen Entscheidungen dahinter.
Die Tabelle übersetzt dieselbe Idee in konkrete Passwort- und Passphrase-Beispiele. Wichtiger als die einzelne Zahl ist das Muster: gleichverteilte Erzeugung und genug unabhängige Entscheidungen schaffen die Sicherheitsreserve.
| Beispiel | Suchraum | Entropie | Einschätzung |
|---|---|---|---|
| 12 zufällige Zeichen aus 64 Symbolen | 64^12 | 72 Bits | Stark für viele typische Anwendungsfälle |
| 16 zufällige Zeichen aus 64 Symbolen | 64^16 | 96 Bits | Sehr starke Voreinstellung für Passwort-Manager |
| 5 Diceware-Wörter aus 7.776 Wörtern | 7.776^5 | 64,6 Bits | Gute Basis für merkbare Passphrase |
| 6 Diceware-Wörter aus 7.776 Wörtern | 7.776^6 | 77,5 Bits | Stärkere merkbare Passphrase |
Wie der Browser sichere Zufälligkeit bereitstellt
Moderne Browser bieten kryptografische Zufälligkeit über die Web Crypto API. Zentral ist crypto.getRandomValues(): Man übergibt ein typisiertes Array, z. B. Uint8Array, der Browser füllt es mit starken Zufallswerten.
Die Web Crypto API war nicht überall sofort da, aber browserseitiger Krypto-Zufall ist seit Jahren flächendeckend verfügbar. MDN führt Crypto und crypto.getRandomValues() als Baseline, u. a. seit Juli 2015 in den großen Browsern.
Hinweis für Entwickler: getRandomValues() ist für kleine Puffer gedacht; pro Aufruf gelten 65.536 Byte Limit — größere Bedarfe in Stücken anfordern.
Vereinfacht sieht es so aus:
const bytes = new Uint8Array(32);
crypto.getRandomValues(bytes);Diese Bytes sind Rohmaterial, noch kein Passwort. Als Nächstes werden sie zu Zeichen, Passphrase-Wörtern, PIN-Ziffern oder API-Key-Bytes.
Diese Abbildung muss sorgfältig sein. Der nächste Abschnitt erklärt Modulo-Bias und wie sichere Generatoren ihn vermeiden.
Was passwords.lu lokal macht
Der Generator fordert sichere Bytes vom Browser an, prüft, ob eine sichere Quelle da ist, und verwirft katastrophale Ausgaben (z. B. nur Nullen oder identische Bytes). Das ist kein Ersatz für den Browser-RNG, sondern eine einfache Plausibilitätskontrolle.
Bei Zeichenpasswörtern werden Bytes per Rejection Sampling auf das gewählte Alphabet abgebildet. Bei Passphrases auf feste Wortlisten. Bei PINs dasselbe: ziehen, bias-erzeugende Werte verwerfen, dann abbilden.
Wichtig: Das erzeugte Passwort bleibt ein lokales Ergebnis der Seite in Ihrem Browser.
Modulo-Bias: der kleine Fehler mit großer Wirkung
Häufiger Fehler: Zufallsbyte nehmen und byte % 62 für ein 62-Zeichen-Alphabet — sieht einfach aus, ist aber schief.
256 teilt sich nicht sauber durch 62; acht Zeichenpositionen bekommen je einen Extra-Byte-Wert — leicht höhere Wahrscheinlichkeit. Das heißt Modulo-Bias.
Bei Spielerei mag das klein wirken. Bei Sicherheitstools soll jedes erlaubte Zeichen so gleichverteilt sein wie die Quelle hergibt; Bias ist unnötig und leicht vermeidbar.
Rejection Sampling: größten Bereich [0, max) wählen, der durch die Alphabetgröße teilbar ist. Für 62 Zeichen 0–247 akzeptieren (248 ist durch 62 teilbar), 248–255 verwerfen und neu ziehen; dann ist byte % 62 unverzerrt.
Deshalb kann ein sicherer Generator mehr Zufallsbytes ziehen als die endgültige Passwortlänge — bewusst verworfene Bytes verhindern subtile Schieflagen.
function randomIndex(byte, alphabetSize) {
const max = Math.floor(256 / alphabetSize) * alphabetSize;
if (byte >= max) return null; // reject and draw again
return byte % alphabetSize;
}Der Generator in diesem Repository folgt diesem Muster für Zeichen; dasselbe Prinzip gilt für Wortindizes und Zahlbereiche: genug Zufall ziehen, bias-erzeugende Werte verwerfen, erst dann abbilden.
Kann Nutzereingabe mehr Zufälligkeit liefern?
Ja: Browser-Zufall lässt sich mit zusätzlicher Nutzer-Entropie mischen. Normalerweise nicht nötig bei gesundem Browser/OS, aber sinnvoll für Transparenz und Defense-in-Depth, wenn man der lokalen Quelle misstraut.
Bekannt ist die Idee „den Topf umrühren“: kleines Spiel oder Interaktion, aus deren Timing und Richtung zusätzliche Unvorhersehbarkeit gewonnen wird.
Eine Snake-artige Erfassung sammelt Richtungswechsel, Tastenabstände, Bewegungsverlauf — nicht als einzige Quelle, sondern gemischt mit Bytes aus crypto.getRandomValues().
Das ist Defense-in-Depth, kein Freibrief für kürzere Passwörter. Eine Minute Snake macht kein 6-Zeichen-Passwort sicher. Länge, großer Suchraum und unverzerrte Erzeugung bleiben zentral.
Ein konkretes Beispiel ist passwordgenerator.ws, mit Snake-artiger Interaktion, um zusätzliche Nutzereingabe einzumischen.
Wie man zwei Quellen richtig mischt
Nicht einfach konkatenieren. Auch ein einzelner Hash reicht nicht, wenn man einen längeren Strom braucht. Besser: eine Key-Derivation Function (KDF) mit Extract- und Expand-Schritt, z. B. HKDF.
Extract verdichtet nicht nur: strukturierte, ungleichverteilte oder teilweise bekannte Eingaben zu einem kurzen pseudozufälligen Schlüssel — Kerngedanke in Krawczyks HKDF-Paper. Expand leitet dann genug Bytes ab und bindet Kontext, z. B. password-generator/v1.
Konzeptuell: Browser-Bytes plus Interaktions-Bytes in eine KDF mit Kontext; deren Ausgabe speist die Erzeugung.
Ist eine Quelle stark und die KDF korrekt, bleibt die Ausgabe unvorhersagbar. Nutzereingabe ist eine zusätzliche Schicht, kein Ersatz für den kryptografischen Browser-RNG.
Das spiegelt ein allgemeines Prinzip: Mehrere Quellen helfen nur, wenn die Mischkonstruktion sauber entworfen ist. Das Paper Many a Mickle Makes a Muckle zeigt das für hybriden Schlüsselaustausch. Passwort-Erzeugung ist einfacher, aber die Lehre gilt: Mischen nützt nur bei sicherer Konstruktion.
browserRandom = crypto.getRandomValues(...)
userRandom = collectKeyboardTimingAndMovement(...)
seed = HKDF-Extract(salt = browserRandom, inputKeyMaterial = userRandom)
bytes = HKDF-Expand(seed, info = "password-generator/v1" || context, length = neededBytes)
password = mapBytesToCharactersWithRejectionSampling(bytes)Produktiv: Standard-KDF, klarer Kontext gegen Zweckverwechslung, genug abgeleitete Bytes, und Rejection Sampling bei Alphabeten.
Soll man dem Browser misstrauen?
Für normale Nutzung ist die Web Crypto API die richtige Basis; der Browser nutzt den kryptografischen RNG des Betriebssystems.
Kein browserbasierter Generator schützt vor vollständig kompromittiertem Endgerät: bösartige Software kann Seiteninhalte lesen, Skripte manipulieren, Clipboard und Tastatur erfassen.
Realistisch braucht es Schichten: vertrauenswürdiger Browser, lokal erzeugen, kryptografischer Zufall, Speicherung im Passwort-Manager.
Vermeiden Sie Übertragung, wenn möglich. Wenn doch geteilt werden muss, nutzen Sie einen sicheren Kanal wie privatenote.ai, integriert in passwords.lu.
Für Kanalwahl siehe unseren Leitfaden zum sicheren Teilen (E-Mail, Chat, sichere Notiz, Passwort-Manager).
Praxis-Fazit
Ein guter Generator soll an der richtigen Stelle „langweilig“ sein: Krypto-Zufall, kein Bias, lokale Erzeugung, klare Annahmen.
Nutzereingabe kann helfen, aber die Basis bleibt: genug Länge, großes Alphabet oder starke Wortliste, abbilden ohne Bias, Geheimnis aus kryptografischer Quelle statt aus Fantasie.
Referenzen
Passwort lokal erzeugen
Probieren Sie den passwords.lu-Generator: Das Ergebnis bleibt in Ihrem Browser und wird nicht an unseren Server gesendet.
Passwort-Generator öffnen