encryption - online - Contraseñas de la aplicación web: bcrypt y SHA256(y scrypt)
salt hash password c# (2)
Con todas las discusiones recientes de contraseñas (por ejemplo, LinkedIn), estoy buscando implementaciones de hash de contraseñas. Después de dos tazas de café y una mañana leyendo, ya no soy más un criptógrafo que cuando comencé. Y realmente no quiero fingir que lo soy.
Preguntás especificas
¿El uso de un ID de usuario único entero falla como una sal efectiva? (crypt () usa solo 16 bits?)
Si simplemente ejecuto sha256 () en un hash una y otra vez hasta que se agote un segundo ¿eso derrota los ataques de fuerza bruta?
Si tengo que hacer estas preguntas, ¿debería usar bcrypt?
Discusión / Explicación:
El objetivo es simplemente si las contraseñas hash de mi usuario se filtraron:
- no sería "fácil" de descifrar,
- descifrar una contraseña no expondría a otros usuarios que usan la misma contraseña).
Lo que he leído para el n. ° 1 es que el cómputo hash debe ser costoso, tomando, digamos, uno o dos segundos para calcular y quizás requiera un bit o memoria (para frustrar el descifrado del hardware).
bcrypt tiene esto incorporado, y scrypt, si entiendo correctamente, es más a prueba de futuro e incluye un requisito mínimo de uso de memoria.
Pero, ¿es un enfoque igualmente efectivo para comer el tiempo "revolviendo" el resultado de sha256 () tantas veces como sea necesario para usar unos pocos segundos y luego almacenar el recuento de bucle final con el hash para luego verificar una contraseña proporcionada?
Para el n. ° 2, usar una sal única para cada contraseña es importante. Lo que no está claro es qué tan aleatoria (o grande) debe ser la sal. Si el objetivo es evitar que todos los que usan "mypassword" como contraseña tengan el mismo hash, ¿no es suficiente simplemente hacer esto ?:
hash = sha256_hex( unique_user_id + user_supplied_password );
o incluso esto, aunque no estoy seguro de que me compre algo:
hash = sha256_hex( sha256( unique_user_id ) + user_supplied_password );
El único beneficio que puedo ver al usar la ID del usuario, además de que sé que es único, es evitar tener que guardar la sal junto con el hash. No es una gran ventaja. ¿Existe un problema real con el uso de la identificación de un usuario como sal? ¿No logra el # 2?
Supongo que si alguien puede robar las contraseñas hash de mi usuario, entonces debo asumir que pueden obtener lo que quieran, incluido el código fuente que genera el hash. Entonces, ¿hay algún beneficio al agregar una cadena aleatoria adicional (la misma cadena) a la contraseña antes de la creación de hash? Es decir:
# app_wide_string = one-time generated, random 64 7-bit *character* string.
hash = sha256_hex( unique_user_id + app_wide_string + user_supplied_password );
He visto eso sugerido, pero no entiendo qué obtengo de eso sobre la sal por usuario. Si alguien quisiera usar el ataque de fuerza bruta, ellos sabrían que "app_wide_string" y lo usarían cuando ejecuten su ataque de diccionario, ¿no?
¿Hay alguna buena razón para usar bcrypt en lugar de enrollar el mío como se describe arriba? ¿Tal vez el hecho de que estoy haciendo estas preguntas es motivo suficiente?
Por cierto, acabo de cronometrar una función hash existente que tengo y en mi computadora portátil y puedo generar aproximadamente 7000 hashes por segundo. No exactamente el uno o dos segundos que a menudo se sugieren.
Algunos enlaces relacionados:
usando sha256 como hash y salazón con la identificación del usuario
SHA512 contra Blowfish y Bcrypt
¿Cuál es la longitud óptima para la contraseña de usuario sal?
¿El uso de un ID de usuario único entero falla como una sal efectiva? (crypt () usa solo 16 bits?)
Normalmente usaría una sal generada aleatoriamente y luego almacenaría ese hash junto con la contraseña encriptada. No importa que el atacante también tenga acceso a la sal, el objetivo es evitar que se use una tabla de búsqueda, lo que obliga al atacante a forzar la fuerza bruta de cada hash individualmente.
crypt simplemente almacena la sal y el hash en una sola cadena, junto con el algoritmo a usar.
Bcrypt es genial porque puedes sintonizar el factor de trabajo de 4 a 31, cada incremento crea un tiempo exponencional requerido, de hecho lo he graficado, en un factor de trabajo de 14 ya lleva más de un segundo, de modo que las computadoras se vuelven más y más rápidas solo necesita cambiar un parámetro y, por supuesto, actualizar los hashes de contraseña ...
Mi principal preocupación con bcrypt es que si el factor de trabajo está configurado en alto, puede sobrecargar su sistema ya que varios usuarios están intentando iniciar sesión para que lo sintonice, dependiendo de la cantidad de inicios de sesión concurrentes y los recursos de su sistema. ..
Las sales aún son necesarias, su principal objetivo es disuadir ataques fuera de línea, si el espacio de sal es demasiado grande, entonces el adversario no podrá generar la tabla de búsqueda, la sal de 64 bits parece un poco baja, brypt tiene 128 las sales poco combinadas con el factor de trabajo lo convierten en todo un desafío para los ataques fuera de línea ... y sí, la sal debe ser aleatoria para cada contraseña, bcrypt generará una para usted, si usa la misma sal para cada contraseña, entonces lo ha logrado más fácil para el adversario comprimir todas las contraseñas usando un ataque en línea.
Bcrypt realmente brilla por los ataques en línea, si has configurado el factor de trabajo correctamente, porque incluso si obtengo el hash, significa que si el ''adversario'' obtiene el hash, el factor de trabajo hace que sea realmente doloroso pasar por todo un diccionario, Tomando varios días y si la contraseña no está en el diccionario, entonces estoy realmente en problemas porque un ataque de fuerza bruta será épico, el espacio de bit de contraseña para bcrypt es bastante grande aunque finito :)
Sha256 puede estar tomando un poco de tiempo ahora, pero finalmente las computadoras se volverán más y más rápidas y será bastante fácil para los ataques, los chicos de Unix pensaron que la cripta era tan lenta que nunca habría sido un problema, y hoy he hecho un ataque en línea en segundos, ataque fuera de línea en días, un ataque de fuerza bruta (atravesando todo el espacio de bits de la contraseña) en semanas ...
- usted quiere que la sal sea lo más grande y aleatoria posible usando solo números me facilita iterar sobre todos los identificadores posibles.
- el sha256 múltiple puede tomar un segundo ahora, pero en el futuro ya no será efectivo, la potencia de procesamiento de las computadoras crece exponencialmente y, por lo tanto, desea un algoritmo que pueda configurarse como tal.
- Estás haciendo lo correcto al hacer preguntas y hacer tu tarea. Si más gente hiciera esto, no tendríamos tantas infracciones.