Cambie de hash bcrypt a sha1 o incluso a texto sin formato, para mejorar el rendimiento

3

Desarrollé una aplicación que es similar en concepto a un servidor FTP. Hay varios cientos de cuentas de usuario y usa bcrypt para almacenar contraseñas con hash.

Todas las contraseñas de usuario son GUID v4 de 128 bits generados aleatoriamente.

Una característica de mi aplicación causa muchos inicios de sesión simultáneos. Cuando esto sucede, bcrypt domina los perfiles de rendimiento y degrada la experiencia del usuario. Quiero reducir la carga de la CPU al reemplazar bcrypt con una función hash con menos uso de la CPU.

Las aplicaciones web utilizan bcrypt para las contraseñas en lugar de hashes mucho más débiles (por ejemplo, SHA-1 de una sola ronda, o incluso ROT13), de modo que el craqueo fuera de línea es repentinamente no trivial.

Pero, dado que una aplicación similar a un servidor FTP simplemente lee / escribe archivos en el disco local, cualquier atacante con acceso a la base de datos de inicio de sesión tendrá acceso a este disco local de todos modos. Así que no creo que el hash cracking fuera de línea sea una amenaza creíble.

Eso solo deja la fuerza bruta en línea, pero como tengo la suerte de tener una garantía de contraseñas seguras (GUID de v4 de 128 bits), eso también es realmente imposible.

Por lo tanto, creo que en esta situación es seguro para mí degradar la seguridad hash a algo significativamente más débil (por ejemplo, SHA-1 de una sola ronda, o incluso ROT13).

Mi pregunta es:

¿He olvidado algo? ¿Este análisis es incorrecto?

    
pregunta mappu 29.06.2018 - 04:03
fuente

1 respuesta

3

Un GUID v4 de 128 bits tiene 122 bits aleatorios. Según RFC 4122 § 4.4 , seis de los bits son fijos, con 122 bits restantes que son aleatorios. Suponiendo que la fuente del generador de números aleatorios que utiliza es criptográficamente segura, una clave generada de esta manera tendrá un espacio de teclas de 2 122 , que es suficiente. Si se usa como una clave para autenticarse en su servicio, no necesita llevarlo a través de un KDF lento. Los KDF lentos están diseñados para hacer que las contraseñas débiles generadas por humanos sean un poco más difíciles de romper. Si la clave ya es demasiado grande para romperla, lo único que se requiere cuando se deriva el hash es el uso de una función unidireccional. Puede pasar la clave de forma segura a través de una sola ronda de SHA-1 o incluso MD5 (estos hash son vulnerables a las colisiones, pero no las imágenes previas, que son lo que importa en el contexto del hashing de contraseñas). Tampoco es necesario que uses una sal, ya que cada clave ya será distinta.

    
respondido por el forest 29.06.2018 - 05:07
fuente

Lea otras preguntas en las etiquetas