No, no es del todo seguro. Veamos cada uno de los comandos:
dd if=/dev/urandom bs=256 count=1 2> /dev/null
Esto leerá un solo bloque de 256 bytes de /dev/urandom , una fuente aleatoria criptográficamente segura. El problema comienza aquí y está relacionado con este límite de 256 bytes. De hecho, ni siquiera necesita usar dd aquí. El siguiente comando es perfectamente capaz de leer desde un dispositivo de bloque por sí solo.
LC_ALL=C tr -dc 'A-Za-z0-9'
Este comando elimina todos los caracteres que no son alfanuméricos. LC_ALL=C limita el conjunto de caracteres a ASCII simple, donde [:alnum:] coincidirá con 62 caracteres. Se eliminarán los símbolos y caracteres no imprimibles. El problema ahora es que solo se asignan 256 bytes a este comando, entonces, ¿qué sucede si muy pocos de esos bytes son alfanuméricos? El comando tr tomará 256 bytes de entrada y escupirá solo un par de bytes de salida si solo un par de bytes coinciden con el filtro.
head -c20
Este comando simplemente trunca la salida a 20 bytes. La salida real variará entre 0 y 20 caracteres. * Estadísticamente, es muy probable que produzca los 20 caracteres completos cada vez.
Se puede hacer una forma superior de obtener caracteres alfanuméricos aleatorios con menos comandos. Esto hará que tr lea tantos datos de /dev/urandom como sea necesario, escupiendo continuamente ASCII alfanumérico al siguiente comando. Tan pronto como head tenga los 20 bytes que ha solicitado, cerrará la tubería, lo que provocará que tr deje de leer datos aleatorios y salga. Esto es lo que debes usar:
LC_ALL=C tr -dc '[:alnum:]' < /dev/urandom | head -c20
Esto garantizará 20 caracteres aleatorios, con una potencia equivalente de log 2 (62 20 ) ≈ 119.1 bits.
* El riesgo es en gran parte teórico. Cada byte tiene una probabilidad (256 - 62) / 256 (alrededor del 76%) de que no es alfanumérico. La probabilidad de que al menos 256-20 bytes no sean alfanuméricos es muy baja, pero no nula: (194/256) 236 ≈ 3.8 × 10 -28 .
Lea otras preguntas en las etiquetas cryptography linux random unix