Digamos que quiero crear una cookie para un usuario. Sería simplemente generar una cadena 1024 bit usando / dev / urandom , y verificar si ¿Ya existe (en bucle hasta que obtenga uno único) suficiente?
¿Debería estar generando la clave en base a otra cosa? ¿Es esto propenso a un exploit de alguna manera?
La respuesta corta es sí. La respuesta larga también es sí. /dev/urandom produce datos que son indistinguibles de la aleatoriedad real, dada la tecnología existente. Obtener "mejor" aleatoriedad de la que proporciona /dev/urandom no tiene sentido, a menos que esté usando uno de los pocos algoritmos criptográficos de "teoría de la información", que no es su caso (lo sabría).
La página del manual para urandom es un tanto engañosa, podría decirse que está equivocada, cuando sugiere que /dev/urandom puede "quedarse sin entropía" y se debería preferir /dev/random ; el único instante en que /dev/urandom podría implicar un problema de seguridad debido a la baja entropía es 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 comenzó a tener cierta actividad en la red, se reunió la aleatoriedad física suficiente para proporcionar una aleatoriedad de alta calidad para todos los usos prácticos (estoy hablando de Linux aquí; en FreeBSD, ese momento momentáneo de leve la debilidad no se presenta en absoluto). Por otro lado, /dev/random tiene una tendencia a bloquearse en momentos inoportunos, lo que lleva a problemas de uso muy reales y molestos. O, para decirlo en menos palabras: usa /dev/urandom y sé feliz; usa /dev/random y disculpa.
( Editar: esta página web explica las diferencias entre /dev/random y /dev/urandom bastante claro.)
Para el propósito de producir una "cookie": dicha cookie debe ser tal que no haya dos usuarios que compartan la misma cookie, y que no sea computacionalmente "adivinar" el valor de una cookie existente. Una secuencia de bytes aleatorios hace eso bien, siempre que use una aleatoriedad de calidad adecuada ( /dev/urandom está bien) y que es suficientemente larga . Como regla general, si tiene menos de 2n usuarios ( n = 33 si toda la población de la Tierra podría usar su sistema), entonces una secuencia de n + 128 bits es lo suficientemente ancha; ni siquiera tiene que verificar una colisión con valores existentes: no lo verá en su vida. 161 bits caben en 21 bytes.
Hay hay algunos trucos que se pueden hacer si desea cookies más cortas y aún así 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 sus cookies confidenciales (es decir, use HTTPS y configure las cookies como "seguras" y "HttpOnly").
Sí, es una gran manera.
La explicación de @ Thomas lo clava. Y tiene toda la razón para criticar la página de manual de /dev/urandom . Spot on.
Pero salta "comprobando si ya existe". Ese cheque no tiene sentido. No va a suceder. (Las posibilidades de que eso suceda son menores que la probabilidad de ser alcanzado por un rayo - varias veces - en el mismo día).
Tenga en cuenta los casos extremos si está usando Linux o NetBSD.
En Linux, querrá asegurarse de que se haya obtenido suficiente entropía después del inicio para inicializar correctamente el CSPRNG, o usar getrandom() llamada al sistema para leer desde /dev/urandom y solo bloquea en el raro caso de que no haya disponible suficiente entropía inicial inicial después del arranque.
En NetBSD, desearías leer /dev/random al menos una vez antes de leer /dev/urandom para asegurarte de que se haya sembrado correctamente.
En FreeBSD y MacOS no hay diferencia entre /dev/random y /dev/urandom .
La respuesta corta aún es usar /dev/urandom .
Consulte Cuándo usar / dev / random vs / dev / urandom para obtener más detalles.
De enlace "Generar verdadera entropía en una computadora es bastante difícil porque nada, Fuera de la física cuántica, es aleatorio. El kernel de Linux usa teclado, mouse, red, y las actividades de disco, con un algoritmo criptográfico (SHA1), para generar datos para el dispositivo / dev / random. Uno de los problemas con esto es que la entrada no es constante, por lo que el grupo de entropía del kernel se puede vaciar fácilmente ". "Otro problema con el uso del teclado, el mouse, la red y la actividad del disco es que en sistemas inactivos, no tripulados y sin disco hay muy poca o ninguna entrada de este tipo. "
Para mí, parece muy posible que / dev / urandom se agote porque / dev / random lo alimenta.
Lea otras preguntas en las etiquetas web-application authentication cryptography linux random