La risposta breve è sì. Anche la risposta lunga è sì. /dev/urandom fornisce dati che sono indistinguibili dalla vera casualità, data la tecnologia esistente. Ottenere una casualità "migliore" rispetto a /dev/urandom fornisce non ha senso, a meno che tu non stia utilizzando uno dei pochi algoritmi crittografici "teorici dell'informazione", che non è il tuo caso (lo sapresti).
La pagina man per urandom è in qualche modo fuorviante, probabilmente del tutto sbagliato, quando suggerisce che /dev/urandom potrebbe "esaurire l'entropia" e /dev/random dovrebbe essere preferito; l'unico istante in cui /dev/urandom potrebbe implicare un problema di sicurezza dovuto alla bassa entropia durante i primi istanti di una nuova installazione automatica del sistema operativo; se la macchina si è avviata fino a un punto in cui ha iniziato ad avere una certa attività di rete, allora ha raccolto abbastanza casualità fisica da fornire casualità di qualità sufficientemente elevata per tutti gli usi pratici (sto parlando di Linux qui; su FreeBSD, quell'istante momentaneo di lieve la debolezza non si verifica affatto). D'altra parte, /dev/random ha la tendenza a bloccarsi in momenti inopportuni, portando a problemi di usabilità molto reali e fastidiosi. Oppure, per dirlo in meno parole:usa /dev/urandom e sii felice; usa /dev/random e scusati.
(Modifica: questa pagina Web spiega le differenze tra /dev/random e /dev/urandom chiaramente.)
Allo scopo di produrre un "cookie":tale cookie dovrebbe essere tale che nessun utente condivida lo stesso cookie e che sia computazionalmente impossibile per chiunque "indovinare" il valore di un cookie esistente. Una sequenza di byte casuali lo fa bene, a condizione che utilizzi una casualità di qualità adeguata (/dev/urandom va bene) e che sia abbastanza lungo . Come regola generale, se hai meno di 2 utenti (n =33 se l'intera popolazione terrestre potesse utilizzare il tuo sistema), allora una sequenza di n+128 bit è abbastanza largo; non devi nemmeno verificare una collisione con i valori esistenti:non lo vedrai nella tua vita. 161 bit sta in 21 byte.
Ci sono alcuni trucchi che sono fattibili se desideri cookie più brevi e desideri comunque evitare di cercare collisioni nel tuo database. Ma questo non dovrebbe essere quasi necessario per un cookie (presumo un contesto basato sul Web). Inoltre, ricorda di mantenere riservati i tuoi cookie (ad esempio, utilizza HTTPS e imposta i flag "secure" e "HttpOnly" per i cookie).
Sì, è un ottimo modo.
La spiegazione di @Thomas lo inchioda. E ha perfettamente ragione a criticare il /dev/urandom pagina man. Perfetto.
Ma salta "controlla se esiste già". Quel controllo è inutile. Non succederà. (Le possibilità che ciò accada sono inferiori alla probabilità di essere colpiti da un fulmine -- più volte -- nello stesso giorno.)