SHA-512 contraseñas de unix. ¿Qué tan seguros son esos hashes, realmente?

Las cifras que usted cita son sobre el número de contraseñas probadas por segundo. Debido a que esta función de hashing de contraseña está incluida, los atacantes no pueden atacar más de una contraseña hash a la vez; de manera similar, no podrán construir y reutilizar tablas precalculadas ("tablas de arco iris"). Además, la función se puede configurar con una serie de iteraciones ("rondas") para que pueda ajustarla a un compromiso entre la cantidad de CPU que está dispuesto a gastar en cada verificación de contraseña y la cantidad de CPU que desea. atacante para gastar en cada intento de craqueo. Si duplica el número de rondas, hace que el trabajo sea dos veces más difícil para todos, incluido.

El número predeterminado de rondas (5000) estaba destinado a ser soportable en computadoras promedio de ese tiempo; las PC recientes son más rápidas y aumentar esa cantidad de rondas para su máquina sería una buena idea.

Sin embargo, los atacantes pueden usar hardware de propósito especial, en particular GPU, para obtener un impulso. El impulso depende de cómo se calcula internamente la función. SHA-512 consiste en una gran cantidad de operaciones aritméticas de 64 bits, y la GPU no está del todo cómoda con eso, por lo que el impulso obtenido con una GPU (en comparación con la CPU genérica, con el mismo presupuesto) no es tan alto como lo sería con SHA-256 (que utiliza solo operaciones de 32 bits). Sin embargo, se espera que una GPU sea unas docenas de veces más rápida que una CPU al intentar descifrar contraseñas. Las cifras exactas dependen mucho de la CPU y de la GPU utilizada, pero sí, es posible una aceleración de 100x (sospecho que subestima su CPU, sin embargo: es multinúcleo y, además, tiene algunas capacidades de cómputo paralelas inherentes con SSE2 o AVX registros).

Otras funciones se basan en más operaciones de acceso a la memoria que dificultan la tarea de una GPU, por ejemplo. bcrypt y scrypt. Consulte esta respuesta para obtener mucha información sobre el hashing de contraseñas. y that para un tratamiento específico de bcrypt vs PBKDF2 (para los fines de la discusión aquí, PBKDF2 es bastante comparable a la función Unix crypt() de la que estamos hablando).

De todos modos, la defensa correcta es no tener una contraseña débil. Si su contraseña es # 11500 en la lista del atacante, entonces es muy débil. Una contraseña razonable tiene al menos 30 bits de entropía, por lo que, en promedio, el atacante tendrá que probar 500 millones de ellos antes de descifrarlos. A 11500 por segundo, tienes algunas horas por delante. Con un poco más de esfuerzo de memoria, puede obtener más de 40 bits de entropía y transformar "unas pocas horas" en "varios años ".

Consulte esta pregunta para discusiones En contraseña entropía. Además, recuerde que el hashing de la contraseña es una segunda línea de defensa que entra en acción solo cuando ya se ha producido una infracción parcial: en un contexto Unix, se supone que /etc/shadow no debe ser leído por usuarios no root, y mucho menos por clientes externos. Por lo tanto, no se preocupe demasiado por el hash de contraseñas y concéntrese en no permitir la inyección de SQL o los desbordamientos de búfer.

Los números son correctos.

El punto principal aquí es que tanto MD5 como SHA están diseñados para ser rápidos. Están destinados a la suma de comprobación de contenido que debe ser lo más rápido posible. Y las computadoras modernas incluso tienen sus propias instrucciones para calcularlas en el hardware.

La mayor diferencia entre MD5 y SHA512 es el espacio de teclas y que la probabilidad de una colisión de hashes en SHA512 es menor en un margen bastante grande en comparación con MD5. Consulte Vulnerabilidades de colisión de MD5 .

El espacio de teclas no desempeña un papel particularmente importante en cuanto a la seguridad de su contraseña.

Para la seguridad criptográfica, debería estar empleando una función lenta como scrypt.

Y para responder a tu otra pregunta:

  

¿O significa que, en promedio, se pueden descifrar 11,500 cuentas de usuario por segundo? Ahora eso sería realmente impresionante.

Bueno, el 'cracking' depende de las contraseñas y de si se usan o no sales.

Lo que significa el número es "cuántos hashes puede hacer esta cosa por segundo".

Entonces, si no tiene sal y el cracker encuentra que el hash 5000 redondo para el texto simple 'foobar' es 'abc123def', puede verificar si este hash se encuentra en el archivo / etc / shadow. El problema de no tener un salt es que dos usuarios diferentes podrían tener la misma contraseña y ambos serían descubiertos al mismo tiempo ya que sus hashes serían los mismos.

Cuando usas contraseñas con sal, el atacante no puede usar tablas de arco iris precalculadas pero necesita atacar a cada usuario por separado con sus Sales propias.

Creo que c / s en este caso significa cálculos / segundo. Cuando se emplea una sal, debe volver a calcular todo para cada hash. Si no se usa sal, puede calcular todo dentro de una ejecución.

Aquí hay una tabla de de los puntos de referencia recientes en diferentes GPU. Como puede ver, esos números son igualmente altos (sé que SHA-512 no está allí pero debería darle una indicación). Esos son la cantidad de hashes calculados por hash. Si agrega rondas, entonces necesita cada recuento de rondas como un solo cálculo de hash. Cada vez más personas se están moviendo hacia Bcrypt y Scrypt, que fueron diseñadas para ser muy poco amigables para ejecutarse en una GPU ya que requieren una cantidad considerable de memoria. Scrypt es incluso mejor que Bcrypt, pero me gustaría referirlo a esta respuesta aquí ¿Algún experto en seguridad recomienda bcrypt para el almacenamiento de contraseñas?

Ahora, la GPU más rápida en esa lista puede calcular aproximadamente 2 656 000 000 hashes por segundo (no crack, ¡calcula!). Una contraseña ASCII normal puede tener 95 caracteres (ASCII solo tiene 95 caracteres imprimibles). Para calcular la cantidad de caracteres posibles y suponiendo que normalmente una contraseña rondaría los 8 caracteres, tendremos las posibilidades 95^8 = 6.6 quadrillion ( 6 634 204 312 890 625 ). Para resolver todos estos problemas, si están utilizando 5000 rondas, obtenemos: 2 656 000 000/5000 = 531 200 c/s . que es significativamente menor que su ejemplo, pero supongamos que están ejecutando una granja de GPU y que realmente pueden calcular en 11 500 000 c/s a 5000 rondas. Venimos a 6.6 quadrillion/11 500 000 = 573 913 043 segundos para calcular todos esos hashes.

Hay 3600 segundos en una hora, 24 horas en un día, así que: 573 913 043 seconds / (24 * 3600) = 6642 days . Eso es todavía 18 años (!) Mucho tiempo para descifrar esas contraseñas y solo estamos dando cuenta de ASCII que no tiene tantos caracteres especiales. Tirar en una sal y las cosas van mucho más despacio. Haga que la contraseña sea de un carácter y se vuelva 100 veces más lenta. Hágalo 12 caracteres más largo (que siempre recomiendo usar como mínimo para cuentas administrativas como root) y bueno, eso es 540 sextillion para usted. Así que incluso

Voy a intentar responder la pregunta señalando que el hash y la sal deben estar en un archivo que esté bien protegido por el sistema operativo.

Una política de seguridad razonable debería limitar las solicitudes de autenticación entrantes a una tasa que posiblemente no podría permitir más de, por ejemplo, 100 intentos de entrada de contraseña por día.

Si el atacante posee los contenidos de /etc/shadow , uno tiene que tener cosas más importantes para preocuparse. Esto normalmente sería una situación extremadamente ideada en la que estar.

Es probable que este sea el motivo por el que no muchas personas están demasiado preocupadas con la configuración de esquemas de hash de contraseñas a prueba de balas: No reveles el hash y la sal. Si existe algún riesgo de hacerlo, cancelar . Debería funcionar bien incluso para esas cosas viejas de MD5; es solo que con eso, el hash, si está comprometido, es mucho más revelador.

Puede que me equivoque sobre este punto, esto es bastante importante (ya que en crypto todos los bits tienen que funcionar bien o es inútil), simplemente considero que la seguridad de algo como SSL es un poco mayor en la lista de prioridades .

Dicho esto, mi ejemplo de la vida real es que estoy distribuyendo la contraseña de root inicial de mi máquina a través de HTTP debido a limitaciones con los medios de arranque del instalador. ¿Por qué no lo hago de una manera que sea más segura? Porque estoy loco de esa manera.

¿La solución? Cree una contraseña muy larga y cámbiela cuando la máquina esté en línea. Esto reduce las posibilidades de un ataque exitoso a efectivamente nulo.

En realidad, no puedo ver una forma sencilla de evitar el problema usando un cifrado basado en scrypt , por ejemplo, que es muy lento para atacar: se debe configurar una contraseña de root para poder acceder en orden. para poder escribir esa frase de cifrado de cifrado. Por lo tanto, puede que no sea posible hasta que el sistema operativo venga empaquetado con un módulo de cifrado que lo admita.

Veo la posibilidad de que la nueva máquina compile scrypt por su cuenta y automáticamente configure una capa de autenticación separada basada en eso. Seguramente habrá muchas piezas para equivocarse con tal esfuerzo.

(Sin embargo, tengo la intención de empaquetar una clave privada SSH cifrada con scrypt para que sea segura por un período algo más largo que el hash de la contraseña)