La reponse courte est oui. La réponse longue est également oui. /dev/urandom donne des données qui ne peuvent pas être distinguées du vrai hasard, compte tenu de la technologie existante. Obtenir un "meilleur" caractère aléatoire que ce que /dev/urandom fournit n'a aucun sens, sauf si vous utilisez l'un des rares algorithmes cryptographiques "théoriques de l'information", ce qui n'est pas votre cas (vous le sauriez).
La page de manuel pour urandom est quelque peu trompeur, voire carrément faux, lorsqu'il suggère que /dev/urandom peut "manquer d'entropie" et /dev/random devrait être préféré; le seul instant où /dev/urandom pourrait impliquent qu'un problème de sécurité dû à une faible entropie survient au cours des premiers instants d'une nouvelle installation automatisée du système d'exploitation ; si la machine a démarré à un point où elle a commencé à avoir une activité réseau, elle a rassemblé suffisamment d'aléatoire physique pour fournir un aléatoire d'assez haute qualité pour toutes les utilisations pratiques (je parle ici de Linux ; sur FreeBSD, cet instant momentané de légère la faiblesse ne se produit pas du tout). Par contre, /dev/random a tendance à se bloquer à des moments inopportuns, ce qui entraîne des problèmes d'utilisation très réels et fastidieux. Ou, pour le dire en moins de mots :utilisez /dev/urandom et soyez heureux; utilisez /dev/random et sois désolé.
(Modifier : cette page Web explique les différences entre /dev/random et /dev/urandom très clairement.)
Dans le but de produire un "cookie":un tel cookie doit être tel que deux utilisateurs ne partagent pas le même cookie, et qu'il soit informatiquement impossible pour quiconque de "deviner" la valeur d'un cookie existant. Une séquence d'octets aléatoires le fait bien, à condition qu'elle utilise un caractère aléatoire de qualité adéquate (/dev/urandom est bien) et qu'il est suffisamment long . En règle générale, si vous avez moins de 2 utilisateurs (n =33 si toute la population de la Terre pouvait utiliser votre système), alors une séquence de n+128 les bits sont assez larges ; vous n'avez même pas besoin de vérifier une collision avec des valeurs existantes :vous ne la verrez pas de votre vivant. 161 bits tiennent dans 21 octets.
Il y a quelques astuces réalisables si vous souhaitez des cookies plus courts tout en évitant de rechercher des collisions dans votre base de données. Mais cela ne devrait guère être nécessaire pour un cookie (je suppose un contexte basé sur le Web). N'oubliez pas non plus de garder vos cookies confidentiels (c'est-à-dire d'utiliser HTTPS et de définir les indicateurs de cookie "sécurisé" et "HttpOnly").
Oui, c'est un excellent moyen.
L'explication de @Thomas le cloue. Et il a tout à fait raison de critiquer le /dev/urandom page de manuel. Parfait.
Mais sautez "vérifier s'il existe déjà". Ce chèque ne sert à rien. Ça n'arrivera pas. (Les chances que cela se produise sont inférieures à la probabilité d'être frappé par la foudre -- plusieurs fois -- dans la même journée.)