La respuesta corta es sí. La respuesta larga también es sí. /dev/urandom produce datos que son indistinguibles de la verdadera aleatoriedad, dada la tecnología existente. Obtener una aleatoriedad "mejor" que /dev/urandom proporciona no tiene sentido, a menos que esté utilizando uno de los pocos algoritmos criptográficos "teóricos de la información", que no es su caso (lo sabría).
La página man para urandom es algo engañoso, posiblemente francamente incorrecto, cuando sugiere que /dev/urandom puede "quedarse sin entropía" y /dev/random debe ser preferido; el único instante donde /dev/urandom podría implicar un problema de seguridad debido a la baja entropía durante los primeros momentos de una instalación nueva y automatizada del sistema operativo; si la máquina arrancó hasta un punto en el que ha comenzado a tener alguna actividad de red, entonces ha reunido suficiente aleatoriedad física para proporcionar aleatoriedad de calidad suficiente para todos los usos prácticos (estoy hablando de Linux aquí; en FreeBSD, ese instante momentáneo de ligera la debilidad no ocurre en absoluto). Por otro lado, /dev/random tiene una tendencia a bloquearse en momentos inoportunos, lo que genera problemas de usabilidad muy reales y molestos. O, para decirlo en menos palabras:usa /dev/urandom y se feliz; usa /dev/random y lo siento.
(Editar: esta página web explica las diferencias entre /dev/random y /dev/urandom claramente.)
Con el propósito de producir una "cookie":dicha cookie debe ser tal que no haya dos usuarios que compartan la misma cookie, y que sea computacionalmente inviable para cualquiera "adivinar" el valor de una cookie existente. Una secuencia de bytes aleatorios lo hace bien, siempre que utilice una aleatoriedad de calidad adecuada (/dev/urandom está bien) y que es suficientemente largo . Como regla general, si tiene menos de 2 usuarios (n =33 si toda la población de la Tierra pudiera usar su sistema), entonces una secuencia de n+128 bits es lo suficientemente ancho; ni siquiera tiene que verificar si hay una colisión con los valores existentes:no lo verá en su vida. 161 bits caben en 21 bytes.
Hay son algunos trucos que son factibles si desea cookies más cortas y aún desea evitar buscar colisiones en su base de datos. Pero esto no debería ser necesario para una cookie (supongo que es un contexto basado en la Web). Además, recuerde mantener la confidencialidad de sus cookies (es decir, use HTTPS y configure las banderas de cookies como "seguras" y "HttpOnly").
Sí, es una gran manera.
La explicación de @Thomas lo clava. Y tiene toda la razón al criticar el /dev/urandom página de manual Perfecto.
Pero omita "comprobar si ya existe". Ese control no tiene sentido. No va a pasar. (Las posibilidades de que eso suceda son menores que la probabilidad de que te caiga un rayo, varias veces, en el mismo día).