Der richtige Generator, Sprache . Nicht alle Passwortgeneratoren sind gleich, und die Sprache, in der dein Tresor geschrieben ist, ist kein technisches Detail. Ein Blick auf Entropie, Generierungsmodi und warum sich Rust unter der Haube durchsetzt. Wenn ein Manager "ein starkes Passwort generiert", stellen sich zwei Fragen: Ist es wirklich unvorhersehbar? (die Qualität des Zufalls) und was passiert damit im Speicher , sobald es angezeigt wurde? Die erste Frage betrifft die Generierungsmodi. Die zweite die Sprache, in der die Anwendung läuft. Dieser Artikel behandelt beides. ~100 bits zufälliges Passwort mit 16 Zeichen (sehr stark) ~77 bits Diceware-Passphrase mit 6 Wörtern (EFF) 12,9 bits zusätzliche Entropie pro Diceware-Wort (Liste mit 7 776 Wörtern) Entropie: die einzige Kennzahl, die zählt Die Stärke eines Passworts misst sich nicht an seiner gefühlten "Komplexität", sondern an seiner Entropie : der Zahl der Unsicherheitsbits für einen Angreifer. Je mehr mögliche Kombinationen es gibt, desto stärker explodieren die Kosten eines Brute-Force-Angriffs. Ein 16 Zeichen langes Passwort aus dem gesamten ASCII-Alphabet erreicht ungefähr 100 bits und liegt damit im Bereich "sehr stark". Ein entscheidender Punkt wird oft vergessen: Entropie zählt nur, wenn die Zufallsquelle ein CSPRNG ist (ein kryptographisch sicherer Pseudozufallszahlengenerator). Ein klassisches Math.random() ist vorhersagbar und macht den Rest wertlos. Gute Implementierungen beziehen Entropie aus dem Betriebssystem: /dev/urandom oder getrandom(2) unter Unix, CNG unter Windows. Vier Familien von Generatoren Ein guter Manager bietet nicht "einen" Generator, sondern mehrere Modi für unterschiedliche Einsatzzwecke. Die Regel lautet: Merkbarkeit kostet Länge . Hier sind die vier Familien, von der dichtesten bis zur menschenfreundlichsten. Der richtige Reflex: Entropie an den Einsatz anpassen Bei einem Webkonto, das durch eine Login-Seite mit Rate-Limit geschützt ist, wird der Angreifer auf einige hundert Versuche pro Sekunde begrenzt: Selbst 50 bits halten geologische Zeiträume stand. Übermäßige Entropie ergibt nur bei Offline-Geheimnissen Sinn (Verschlüsselungsschlüssel, Seed einer Krypto-Wallet), bei denen ein Angriff massiv parallelisiert werden kann. Für solche Geheimnisse von sehr hohem Wert bleiben echte physische Würfel (Diceware im wörtlichen Sinn) die ultimative Option: Sie beseitigen jede Abhängigkeit von der Qualität des CSPRNG oder von einem kompromittierten Browser. Warum Rust den Unterschied macht Ein gutes Passwort zu generieren ist nur die Hälfte der Arbeit. Die andere Hälfte: es nicht herumliegen lassen . Sobald dein Passwort angezeigt oder entschlüsselt wurde, lebt es im Arbeitsspeicher, und genau dort wird die Sprache der Anwendung entscheidend. Microsoft berichtete, dass 70 % der Sicherheitslücken , auf die das Unternehmen stößt, Speicherfehler sind (buffer overflow, use-after-free usw.). Google beobachtete denselben Anteil bei Chrome und Android. Genau diese Fehlerklassen eliminiert Rust zur Kompilierzeit durch sein Eigentumsmodell ( ownership ) und Ausleihmodell ( borrowing ), ganz ohne Garbage Collector. Die Zahlen von Google sind eindeutig: Die Speicherlücken in Android fielen von 223 im Jahr 2019 auf weniger als 50 im Jahr 2024 und lagen damit erstmals unter 20 % aller Schwachstellen. Neuer Rust-Code weist eine bis zu 1000× geringere Dichte an Speicherfehlern auf als historischer C/C++-Code, zusätzlich zu 4× weniger Rollbacks und 25 % weniger Review-Zeit. 1. Speichersicherheit ohne Garbage Collector. Sprachen wie Java oder Python sind memory-safe, aber ihr Garbage Collector gibt Speicher nicht deterministisch frei: Ein Geheimnis kann dort unbegrenzt überleben, offen für einen memory dump oder einen cold-boot-Angriff. Rust gibt Speicher deterministisch frei, sobald die Daten nicht mehr verwendet werden. 2. Explizites Löschen mit zeroize . Rust garantiert nicht, dass freigegebener Speicher überschrieben wird. Die Crate zeroize schließt diese Lücke: Wenn ein Geheimnis in Zeroizing verpackt wird, wird es mit Nullen überschrieben, über einen volatilen Schreibvorgang, den der Compiler nicht wegoptimieren kann, genau in dem Moment, in dem es den Scope verlässt. 3. Ein Typsystem, das korrekte Kryptonutzung erzwingt. Rusts strenges Typsystem erlaubt es festzulegen, wie sensible Daten verwendet werden dürfen, und wie oft. Man kann zum Beispiel einen Schlüssel modellieren, der nur einmal eingesetzt werden darf; jede Wiederverwendung lehnt der Compiler ab. Technische Ehrlichkeit: Rust ist kein Zauberstab unsafe -Code und Drittanbieter-Abhängigkeiten bleiben Angriffsflächen. Google hat beispielsweise eine Schwachstelle (CVE-2025-48530) in einem unsafe -Block eines Rust-Parsers behoben, bevor etwas in Produktion ging. Speichersicherheit ist eine Schicht , kein Selbstzweck: Sie wird mit Defense-in-Depth kombiniert (robuste KDF wie Argon2id, zero-knowledge-Architektur, Auto-Lock, MFA). Was man von einem Manager verlangen sollte Bei der Auswahl, oder Bewertung, eines Passwortmanagers zählen vier konkrete Fragen: 1. Stützt sich der Generator auf einen System-CSPRNG und zeigt er die Entropie in bits an? 2. Bietet er einen Diceware/EFF-passphrase-Modus für das Master-Passwort? 3. Erfolgt die Generierung lokal (client-side) , ohne Übertragung über einen Server? 4. Ist der sensible Kern in einer memory-safe Sprache geschrieben und löscht Geheimnisse explizit? Sichere Generierung. Ein Tresor, der auf Dauer ausgelegt ist. Passwörter mit hoher Entropie, merkbare passphrases und ein Kern, der für Speichersicherheit gebaut ist. Informativer Inhalt zu Bildungszwecken. Die genannten Statistiken (Google/Android, Microsoft, Diceware/EFF) stammen aus den oben aufgeführten Quellen. Die Rust-Codebeispiele sind illustrativ und vereinfacht.