Entwicklertools · UUID Generator
Math.random vs crypto.getRandomValues: Wie jeder Generator funktioniert
· Wie es funktioniert
UUID Kryptographie Browser-APIs
Beide geben Zahlen zurück, die zufällig aussehen, aber eine ist eine kleine deterministische Zustandsmaschine und die andere wird vom Betriebssystem gespeist. Hier erfahren Sie, was jeder unter der Haube tut und warum UUIDs den zweiten verwenden müssen.
Das Forum-Snippet, das ein UUID aus Math.random erstellt – warum es gut aussieht und jeden Gelegenheitstest besteht
Eine Forumsantwort bietet eine schnelle UUID-Fabrik in acht Zeilen: Rollen Sie Werte aus Math.random und formatieren Sie sie in das 8-4-4-4-12-Layout. Der Code sieht gut aus und besteht jeden Gelegenheitstest. Jeder Identifikator sieht anders aus und eine kurze Probe zeigt kein offensichtliches visuelles Muster. Das ist nicht die Eigenschaft, die ein security-sensitive-Bezeichner benötigt. JavaScript gibt Math.random als pseudo-random-Quelle an, erfordert jedoch keinen kryptografischen Widerstand gegen Vorhersage. Zu den entsprechenden Aufgaben gehören Simulationen, Spiele und Mischen. Sobald ein Identifikator den Zugriff, die Objektentdeckung oder eine andere kontradiktorische Entscheidung beeinflussen kann, ist sein äußeres Erscheinungsbild kein Beweis mehr. Der dokumentierte Vertrag des Generators ist wichtiger als eine Seite mit plausible-looking-Ausgaben.
Inside Math.random – ein gesetzter Pseudozufallsalgorithmus mit einem festen internen Zustand, der auf Geschwindigkeit und statistische Streuung und nicht auf Geheimhaltung ausgelegt ist
Da Math.random nicht als kryptografischer Generator angegeben ist, dürfen seine Ausgaben nicht als Beweis dafür betrachtet werden, dass zukünftige Werte einem Beobachter verborgen bleiben. crypto.getRandomValues hat einen anderen Plattformvertrag: Es füllt ein ganzzahliges Array mit kryptografisch starken Werten. Die Web-Crypto-Spezifikation überlässt den genauen Generator dem Benutzeragenten, daher sollte der Anwendungscode keinen bestimmten Algorithmus, keine bestimmte Seed-Größe oder kein bestimmtes Entropiegerät beanspruchen. ToolAcre benötigt nur die unterstützte Grenze: Der Browser stellt sichere Zufallsbytes bereit, JavaScript empfängt das gefüllte Uint8Array und der UUID-Code legt die Versions- und Variantenfelder fest. Diese Anweisung ist sowohl nützlich als auch über Browser hinweg übertragbar, deren interne Implementierungen unterschiedlich sind.
Warum die Beobachtung von Ausgaben den Zustand offenbaren kann – wie ein kleiner Zustand bedeutet, dass eine Reihe von Werten es jemandem ermöglichen kann, die nächsten vorherzusagen
Anwendungscode empfängt kryptografisch starke Werte von getRandomValues, anstatt einen JavaScript PRNG-Zustand zu implementieren oder verfügbar zu machen. Der Sicherheitsunterschied zeigt sich in realen Systemen. Eine aus Math.random erstellte Kennung ist überall dort ungeeignet, wo eine Vorhersage Konsequenzen hätte, da ein Angreifer mit der Fähigkeit, das Netzwerk (oder jedes System, in dem frühere UUIDs sichtbar sind) zu lesen, die nächste vorhersagen kann. Ein v4 UUID von crypto.getRandomValues ist an sich kein Authentifizierungstoken (Sie benötigen weiterhin Ablauf, Hashing, rate-limiting), aber der Generator ist so konzipiert, dass er Vorhersagen widersteht. ToolAcre weigert sich, einen Bezeichner zu generieren, wenn seine sichere Quelle fehlt, anstatt stillschweigend auf eine vorhersehbare Formel herabzustufen. Math.random wurde mit subtilen Verteilungsfehlern in den wichtigsten Engines ausgeliefert. Eine Ausgabesequenz kann abwechslungsreich aussehen, ohne die für secret-bearing-Rollen erforderliche gegnerische Unvorhersehbarkeit bereitzustellen.
Innerhalb von crypto.getRandomValues fragt der Browser nach dem CSPRNG des Betriebssystems, das Hardware- und Systementropie mischt und so konzipiert ist, dass es unvorhersehbar ist
Engine-spezifische Algorithmen und ihr statistisches Verhalten können sich ändern; Weder eine visuelle Inspektion noch ein zufälliger Verteilungstest werten Math.random zu einer kryptografischen Quelle auf. Kollisionsberechnungen gehen auch von unabhängigen Ausgaben aus dem angegebenen Raum aus. Wenn ein Generator den Zustand wiederholt, falsch gesät wird oder durch eine deterministische Vorrichtung ersetzt wird, ist diese Annahme fehlgeschlagen und die Formel beschreibt die Implementierung nicht mehr. Beide APIs können Zeichenfolgen erzeugen, die gleichermaßen unregelmäßig aussehen. Das Bedrohungsmodell trennt sie: Werte, die der Vorhersage widerstehen müssen, verwenden crypto.getRandomValues, während Simulationen und non-adversarial-Mischungen Math.random verwenden können. Die Wahl ergibt sich aus der Konsequenz der Vorhersage, nicht aus Zeichensetzung oder offensichtlicher Vielfalt in einer Stichprobe.
Bearbeitetes Beispiel – mit jeder Methode die gleiche Anzahl von Bezeichnern generieren und vergleichen, was ein Beobachter daraus ableiten könnte
Der Generator ToolAcre UUID verwendet ausschließlich crypto.getRandomValues; Es wird niemals Math.random verwendet, da die Kosten eines vorhersehbaren UUID immer höher sind als die Kosten eines etwas langsameren Generators. Der kryptografische Unterschied ist durch ein Bedrohungsmodell messbar. Ein Angreifer, der UUIDs fälschen möchte, muss entweder die Kennung direkt erraten oder den random-number-Generator zerstören. Direktes Raten ist nicht der Vergleich, den dieser Artikel quantifiziert; Die unterstützte Schlussfolgerung ist, dass Web Crypto für kryptografische Zufälligkeit gedacht ist, Math.random jedoch nicht. Ein CSPRNG und ein Math.random legen unterschiedliche Verträge offen: Ersterer ist auf security-sensitive Zufälligkeit ausgelegt, während letzterer kein solches Versprechen enthält. Ein System, das Math.random für Bezeichner verwendet, hat die kryptografische Eigenschaft verloren; Die Sicherheit hängt nun davon ab, dass die Reihenfolge der generierten UUIDs geheim gehalten wird. Wenn auch nur ein UUID ausläuft, ist die gesamte zukünftige Generation gefährdet.
Historische Verteilungsfehler – eine Erinnerung daran, dass Engines Math.random-Implementierungen mit sichtbar ungleichmäßiger Ausgabe geliefert haben, qualitativ beschrieben
Wenn die Anwendung UUIDs in einem Protokoll, einer Datenbank oder einem Versionskontrollverlauf speichert, ist das Leck nahezu unvermeidlich. Die Bibliothek ToolAcre erzwingt die Verwendung von crypto.getRandomValues und weigert sich, ein UUID zu generieren, wenn der sichere Kontext (HTTPS oder localhost) nicht verfügbar ist. Diese Entwurfsentscheidung verhindert den stillen Fallback auf Math.random, der viele hand-rolled-Implementierungen störte. In Node.js verwendet die Bibliothek das Kryptomodul; In Browsern wird die Web-Kryptowährung API verwendet. Beide unterstützten Pfade fordern von der Plattform eine kryptografisch starke Zufälligkeit. Die Implementierung erhebt keinen Leistungsanspruch, da Engine, Gerät und Arbeitslast das Timing bestimmen. Für Identifikatoren ist der Sicherungsvertrag die entscheidende Eigenschaft. Warum sich der Industriestandard auf crypto.getRandomValues festgelegt hat, ist eine kurze Geschichte des Missbrauchs von UUID. Frühe Systeme nutzten Systemzeit, Netzwerkschnittstellen und Hardware-Uhren, um Identifikatoren zu generieren.
Was dies nicht abdeckt, ist die statistische Qualität beider Generatoren für Simulationen, was eine andere Frage als die Unvorhersehbarkeit ist
Zeitbasierte, knotenbasierte und zufällige UUID-Versionen lösen unterschiedliche Zuordnungsprobleme; Man sollte nicht für jedes frühere Design als lineare Reparatur dargestellt werden. Für Version 4 definiert RFC 9562 Zufallsfelder und erörtert separat die Unerratenbarkeit. Eine Migration weg von Math.random ändert daher die Qualität neu generierter Werte, ohne die textuelle Form von UUID zu ändern. Vorhandene Bezeichner bleiben Datenbankschlüssel; Ihre Neugenerierung würde Referenzen zerstören. Neue Werte können Web Crypto sofort verwenden, während die Autorisierung weiterhin jeden alten oder neuen UUID als Identifikator und nicht als Berechtigungsnachweis behandeln muss. Dokumentieren Sie den Grenzwert, damit die Notfallhelfer wissen, welcher Generator welche Population erzeugt hat.
Fazit: Wählen Sie den Generator nach Bedrohung und nicht nach Aussehen – der ToolAcre UUID-Generator verwendet ausschließlich CSPRNG, niemals Math.random()
Bei der Validierung sollte zwischen alten (nicht zur Geheimhaltung geeigneten) und neuen (CSPRNG-gestützten) IDs unterschieden werden. Der Übergang sollte in der Dokumentation vermerkt sein. Der ToolAcre-Generator erzeugt nur crypto.getRandomValues UUIDs; Es wird nicht versucht, Bezeichner aus anderen Quellen zu validieren oder neu zu generieren. Der ToolAcre-Generator demonstriert Best Practice, indem er ein Downgrade auf eine schwächere Zufallsquelle ablehnt. Wenn crypto.getRandomValues nicht verfügbar ist, meldet das Tool einen Fehler, anstatt Math.random stillschweigend zu verwenden. Dieses Designprinzip gilt für jedes security-critical-System: lautstark scheitern, statt lautlos mit einer schwachen Sicherheitsgarantie erfolgreich zu sein. Ein Entwickler, der "UUID generation failed: crypto API not available" sieht, muss das zugrunde liegende Problem beheben (Upgrade auf HTTPS, Korrektur des sicheren Kontexts oder Bereitstellung eines geeigneten Fallbacks). Ein Entwickler, der stillschweigend UUIDs erhält, die aus Math.random erstellt wurden, hat keinen Hinweis darauf, dass das System kompromittiert ist. Die Bibliothek ToolAcre gibt Ehrlichkeit Vorrang vor Bequemlichkeit.