Estoy implementando un servicio de token de una sola vez. Cada uno de estos token de una sola vez representa algunos datos / acciones del lado del servidor asociados con él (por ejemplo, una acción de 'confirmación de correo electrónico'), de modo que mi servicio web pueda verificar y tomar medidas cuando los reciba sin sesión. (desde dentro del enlace de confirmación de un correo electrónico; desde un escaneo de código qr; ...)
Este token debería ser muy difícil de adivinar o falsificar. Así que creo que una cadena larga y aleatoria (de / dev / urandom) debería ser lo suficientemente buena. Pero de enlace :
Una contraparte de / dev / random es / dev / urandom ("unlimited" [5] / fuente aleatoria sin bloqueo [4]) que reutiliza el Grupo interno para producir más bits pseudoaleatorios. Esto significa que el la llamada no se bloqueará, pero la salida puede contener menos entropía que la Lectura correspondiente de / dev / random. Mientras que / dev / urandom está todavía diseñado como un generador de números pseudoaleatorios adecuado para la mayoría propósitos criptográficos, algunas personas afirman / dev / urandom como no recomienda [¿quién?] para la generación de claves criptográficas a largo plazo. Sin embargo, en general este no es el caso porque una vez que el grupo de entropía es impredecible y no pierde seguridad por un número reducido de bits.
Y también he leído algo de código en la sesión de werkzeug enlace
def _urandom():
if hasattr(os, 'urandom'):
return os.urandom(30)
return text_type(random()).encode('ascii')
def generate_key(salt=None):
if salt is None:
salt = repr(salt).encode('ascii')
return sha1(b''.join([
salt,
str(time()).encode('ascii'),
_urandom()
])).hexdigest()
Entonces, mi pregunta es: ¿es hash(time()+urandom())
genera más cadenas 'aleatorias' que pure urandom()
? ¿Cuál es el propósito de usar una función hash aquí?