Utilidad de bcrypt (UUIDv4 ())

Question

Utilidad de bcrypt (UUIDv4 ())

#1 de Tom Leek (4 votos)

2

Uno de mis colegas está trabajando en la obtención de los ID y los secretos de los clientes de OAuth 2 para nuestro servidor OAuth y ha desarrollado este esquema en el que no solo usaría UUID v4 para generar valores aleatorios, sino que también los codificará. Otro colega preguntó cuál es el propósito de cifrarlos, a lo que obtuvo la respuesta de que solo UUID v4 "pierde 4 bits de aleatoriedad" (lo que haría que los valores generados sean más fáciles de adivinar).

La pregunta parecía legítima en lo que a mi conocimiento se refiere, pero no pude encontrar nada sobre la parte de "pierde 4 bits de aleatoriedad".

Mi pregunta es si el uso de bcrypt aquí en realidad tiene un beneficio adicional y, en caso afirmativo, cuánto beneficio adicional.

No tengo mucho conocimiento en lo que respecta a criptografía, cifrados, números aleatorios criptográficos, etc., por lo que se agradecerán los punteros a otras lecturas relacionadas con esta pregunta en particular.

oauth random entropy bcrypt

pregunta Ionuț G. Stan 11.07.2014 - 15:53

fuente

1 respuesta

Lea otras preguntas en las etiquetas oauth random entropy bcrypt

¿Cómo podría alguien cambiar una contraseña de root sin modificar la fecha 'chage -l root'? ¿Cómo hago un ejemplo funcional de un exploit de "Dangling Pointers"? (o donde lo encuentro en línea)

score 4 · Accepted Answer

Los UUID de tipo "v4" se deben generar con 122 bits aleatorios:

o  Set all the other bits to randomly (or pseudo-randomly) chosen
   values.

Sin embargo, no se dice que dichos bits deban provenir de un criptográficamente seguro PRNG (la sección 4.5 lo recomienda , pero no lo exige).

SI los 122 bits de hecho provienen de un PRNG seguro, entonces son inmunes a la búsqueda exhaustiva, porque ese espacio es demasiado grande para una exploración práctica (consulte esta respuesta para más detalles). Agregar bcrypt es, por lo tanto, un desperdicio de CPU y una complejidad extra gratuita, lo que nunca es bueno, especialmente en seguridad.

Si los 122 bits no son producidos por un PRNG seguro, entonces tiene un problema. Es concebible que bcrypt pueda mitigar un poco el problema, de la misma manera que bcrypt es bueno para tolerar contraseñas , que solo se puede describir como "claves de baja entropía". Pero realmente depende de cuán insegura sea la PRNG. Una "seguridad" de PRNG se basa en su imprevisibilidad; Aquí, "cuánto" el atacante no conoce los 122 bits. Si ese "cuánto" es realmente bajo, entonces bcrypt no salvará el día.

Por lo tanto, mi opinión es que cuando el cifrado de un UUID es apropiado, entonces el UUID es no apropiado para usarlo como una clave secreta, y deberías corregirlo en su lugar.

En cuanto a los "3 bits extra de aleatoriedad", esto parece confuso, confuso, o ambos. No tengo idea de dónde viene esa idea.