¿Es tolerable usar SHA-512 para almacenar contraseñas?

38

Sé que las mejores opciones para usar para almacenar contraseñas son bcrypt / PBKDF2 / scrypt.

Sin embargo, suponga que tiene que auditar un sistema y utiliza SHA-512 con salt. Eso está bien"? ¿O es una vulnerabilidad que debe abordarse, incluso si su sitio es un foro de discusión?

Por supuesto, si es débil, debe tratarse, ya que las contraseñas de los usuarios también se pueden usar en otros sitios. La pregunta es: ¿es demasiado débil para no tolerarlo como una posibilidad?

    
pregunta Bozho 22.02.2014 - 09:23
fuente

4 respuestas

41
  

Sin embargo, suponga que tiene que auditar un sistema y utiliza SHA-512 con salt. Eso está bien"? ¿O es una vulnerabilidad que debe abordarse, incluso si su sitio es un foro de discusión?

Suponiendo que se trata de una sal criptográfica aleatoria por nombre de usuario por mucho tiempo, y su auditoría no tiene que seguir ninguna norma reglamentaria o legal en particular, entonces sugeriría un poco de matemáticas.

Es un foro de discusión, por lo que asumo que los usuarios nunca tienen que cambiar sus contraseñas. Así, las preguntas básicas son:

  • ¿Por cuánto tiempo debería ser segura una contraseña "normal", en promedio?
  • ¿Cuál es el espacio de claves asumido de una contraseña "normal"?
  • ¿A qué velocidad espera que un atacante pueda probar las contraseñas en un ataque sin conexión?

Tenemos la ecuación básica:  - Tiempo promedio de seguridad * 2 = Tiempo de agotamiento del espacio de teclado

Usamos las siguientes ecuaciones útiles:

  • Tiempo de agotamiento del espacio de claves * tasa de prueba = espacio de claves mínimo para contraseñas "normales"
  • Espacio de claves mínimo para contraseñas "normales" / tiempo de agotamiento del espacio de claves = tasa de ataque máxima
  • espacio de teclas mínimo para contraseñas "normales" / tasa de prueba = tiempo de agotamiento del espacio de teclas

Por lo tanto, si tomamos este ejemplo:

  • 30 días de seguridad para una contraseña "normal", en promedio
  • Las contraseñas "normales" son la lista de palabras de fuga de phpbb * el conjunto de reglas "d3ad0ne"

Tenemos el resultado:

  • 30 * 2 * 24 * 3600 = 5184000 segundos de tiempo de agotamiento del espacio de teclas
  • 184389 * 35408 = 6528845712 posibles contraseñas (espacio clave)
  • 6528845712/5184000 = 1259 intentos / segundo es la tasa de ataque máxima.
  • Esto es descaradamente insuficiente, ya que OclHashcat enumera una tasa de 797 millones de intentos por segundo para una sola PC (8x AMD R9 290Xstock core reloj).

Si vamos por el otro lado, tenemos:

  • Las contraseñas "normales" son la lista de palabras de fuga de phpbb * el conjunto de reglas "d3ad0ne"
  • La tasa de prueba es de 797 millones de intentos por segundo

Por lo tanto, obtenemos:

  • 184389 * 35408 = 6528845712 posibles contraseñas (espacio clave)
  • 797000000 intentos / seg
  • 6528845712/797000000 = 8 segundos.
  • Obviamente, con una sola computadora moderna y estas suposiciones de espacio de teclas, sus usuarios "normales" se verán afectados en 8 segundos.

Tenga en cuenta que si tuviera 1,000 usuarios, sería:

  • 1000 * 8 = 8000 segundos, o 8000/3600 = 2.2 horas en promedio para descifrar todas las contraseñas "normales" de las 1000.

Ahora, si asume que sus usuarios seleccionan contraseñas de 8 caracteres criptográficamente aleatorias, con mayúsculas, minúsculas y números (¡buena suerte con eso!):

  • 62 ^ 8 = 218340105584896 espacio de teclas
  • 797000000 intentos / seg
  • 218340105584896/797000000 = 273952 segundos
  • 273952/3600 = 76 horas. En general, todavía es insuficiente, pero claramente si puedes aumentar la longitud mínima un poco (y mantener la aleatoriedad y el conjunto de caracteres perfectos), entonces estarás bien.

Primero elige los números que tengan sentido, luego haz los cálculos. La respuesta será obvia después de eso.

    
respondido por el Anti-weakpasswords 22.02.2014 - 11:13
fuente
41

No, estás resolviendo el problema incorrecto.

Pasar de SHA-1 o SHA-256 a SHA-512 no hace que resquebrajar el hash sea mucho más difícil. Los hashes generalmente no se invierten mediante alguna propiedad matemática del algoritmo, por lo que avanzar el algoritmo no cambia mucho la seguridad.

En su lugar, los hash son forzados por la fuerza bruta utilizando una técnica de "adivinar y verificar" . Usted adivina una contraseña, calcula el hash y luego verifica si ha adivinado correctamente. Y repita, y repita, y repita hasta que finalmente lo obtenga.

Entonces, la forma de ralentizar al atacante es ralentizar el proceso de hash. Si lleva más tiempo comprobar cada contraseña, el atacante no puede adivinar tantas. Y, en este caso, SHA-512 no es mucho más lento que SHA-256 o SHA-1. o MD5. Así que realmente no estás agregando ninguna seguridad.

En cambio, el hilo común entre las técnicas como bcrypt, PBKDF2 y scrypt es que todas ejecutan la función de hashing una y otra vez, miles de veces, solo para una única conjetura de contraseña. Entonces, digamos que un sitio utiliza PBKDF2 en 10,000 iteraciones: esto significa que el atacante debe gastar tanto tiempo y recursos en una sola suposición como lo haría en un diccionario completo de 10,000 contraseñas. Al reducir la velocidad del atacante, limitas la cantidad de contraseñas que finalmente puede adivinar y, por lo tanto, disminuye la probabilidad de que él adivine correctamente.

Muchas instalaciones adaptan su configuración para que se ajuste al hardware existente. Así, por ejemplo, LUKS utiliza un mínimo de 1000 iteraciones, o lo que sea necesario para consumir 1/8 de segundo. el que sea más largo.

    
respondido por el tylerl 22.02.2014 - 21:43
fuente
30

Me temo que no es posible responder si esto está "bien" o no con respecto a una auditoría, sin el contexto de la organización que está realizando la auditoría. Un nivel de riesgo que está bien para una compañía puede ser completamente inaceptable para otra.

En términos de las especificaciones técnicas de su pregunta. Suponiendo que está usando SHA-512 con sal por usuario, esto puede considerarse correcto dependiendo de las amenazas que enfrenta y el impacto de una violación. Definitivamente es mejor que MD5 sin sal, pero obviamente no es tan bueno como bcrypt / PBKDF2 / scrypt.

Sería relativamente resistente a cosas como los ataques de la mesa del arco iris pero no a la resistencia (como dice @terrychia) a un atacante dedicado con instalaciones de craqueo asistido por hardware y tiempo para gastar.

Por lo tanto, si está bien para usted podría depender de si espera que el grado de atacante se dirija al sitio y el nivel de impacto que tendría una brecha.

Si, por ejemplo, una infracción le costaría $ 1 millón en pérdidas directas / indirectas, parecería una mala idea confiar en una configuración que se reconoce como menos que ideal.

Sin embargo, si una infracción le costaría $ 100, entonces es probable que el tiempo de desarrollador necesario para implementar la solución no valga la pena.

    
respondido por el Rоry McCune 22.02.2014 - 10:15
fuente
15

No, no está bien.

El SHA512 simple se puede forzar con una fuerza bruta a velocidades bastante rápidas usando cosas como GPU / FPGA / ASIC. Si hay alguna posibilidad de arreglarlo, definitivamente cámbielo para usar algo como bcrypt, scrypt o pbkdf2.

    
respondido por el Ayrx 22.02.2014 - 09:29
fuente

Lea otras preguntas en las etiquetas