Die kurze Antwort ist ja. Die lange Antwort ist auch ja. /dev/urandom liefert Daten, die angesichts der vorhandenen Technologie nicht von echter Zufälligkeit zu unterscheiden sind. Eine "bessere" Zufälligkeit als bei /dev/urandom bietet, ist bedeutungslos, es sei denn, Sie verwenden einen der wenigen "informationstheoretischen" kryptografischen Algorithmen, was nicht Ihr Fall ist (Sie würden es wissen).
Die Manpage für urandom ist etwas irreführend, wohl geradezu falsch, wenn es darauf hindeutet, dass /dev/urandom kann "keine Entropie mehr haben" und /dev/random sollte bevorzugt werden; der einzige Moment wo /dev/urandom vielleicht implizieren, dass ein Sicherheitsproblem aufgrund niedriger Entropie in den ersten Momenten einer neuen, automatisierten Betriebssysteminstallation auftritt; Wenn die Maschine bis zu einem Punkt hochgefahren ist, an dem sie begonnen hat, Netzwerkaktivität zu haben, dann hat sie genug physische Zufälligkeit gesammelt, um eine Zufälligkeit von ausreichend hoher Qualität für alle praktischen Anwendungen bereitzustellen (ich spreche hier von Linux; unter FreeBSD dieser momentane Moment der leichten Schwäche tritt gar nicht auf). Andererseits /dev/random neigt dazu, zu ungünstigen Zeiten zu blockieren, was zu sehr realen und lästigen Usability-Problemen führt. Oder, um es mit weniger Worten auszudrücken:Verwenden Sie /dev/urandom und sei glücklich; Verwenden Sie /dev/random und es tut mir leid.
(Bearbeiten: diese Webseite erklärt die Unterschiede zwischen /dev/random und /dev/urandom ganz klar.)
Zum Zweck der Erstellung eines „Cookies“:Ein solches Cookie sollte so beschaffen sein, dass keine zwei Benutzer dasselbe Cookie teilen und dass es rechnerisch unmöglich ist, den Wert eines vorhandenen Cookies zu „schätzen“. Eine Folge von Zufallsbytes tut das gut, vorausgesetzt, sie verwendet Zufälle von ausreichender Qualität (/dev/urandom ist in Ordnung) und dass es lang genug ist . Als Faustregel gilt, wenn Sie weniger als 2 haben Benutzer (n =33 wenn die gesamte Erdbevölkerung Ihr System nutzen könnte), dann eine Folge von n+128 Bits ist breit genug; Sie müssen nicht einmal nach einer Kollision mit bestehenden Werten suchen:Sie werden sie zu Lebzeiten nicht sehen. 161 Bit passen in 21 Byte.
Es gibt Einige Tricks, die machbar sind, wenn Sie kürzere Cookies wünschen und trotzdem vermeiden möchten, in Ihrer Datenbank nach Kollisionen zu suchen. Für ein Cookie dürfte dies aber kaum nötig sein (ich gehe von einem webbasierten Kontext aus). Denken Sie auch daran, Ihre Cookies vertraulich zu behandeln (d. h. HTTPS zu verwenden und die Cookie-Flags „secure“ und „HttpOnly“ zu setzen).
Ja, es ist eine großartige Möglichkeit.
@ Thomas 'Erklärung bringt es auf den Punkt. Und er hat vollkommen recht, wenn er die /dev/urandom kritisiert Manpage. Genau richtig.
Aber überspringen Sie "Prüfen, ob es bereits existiert". Diese Überprüfung ist sinnlos. Es wird nicht passieren. (Die Wahrscheinlichkeit, dass dies passiert, ist geringer als die Wahrscheinlichkeit, vom Blitz getroffen zu werden – mehrmals – am selben Tag.)