¿Cómo se usa una sal para hacer una contraseña más segura si se almacena en la base de datos?

Estoy aprendiendo Rails, por el momento, pero la respuesta no tiene que ser específica de Rails.¿Cómo se usa una sal para hacer una contraseña más segura si se almacena en la base de datos?

Así que, como yo lo entiendo, un sistema de contraseña segura funciona así:

usuario crea una contraseña
sistema encripta la contraseña con un algoritmo de cifrado (por ejemplo SHA2).
Almacena el hash de la contraseña cifrada en la base de datos.

Tras el intento de inicio de sesión:

usuario intenta iniciar sesión
sistema crea hash del intento con el algoritmo de cifrado misma
sistema compara con el hash del intento de hash de la contraseña en la base de datos.
Si coinciden, se les deja entrar. De lo contrario, tienen que volver a intentarlo.

Según tengo entendido, este enfoque está sujeto a un ataque de arcoíris, en el que puede ocurrir lo siguiente.

Un atacante puede escribir un script que esencialmente prueba cada permutación de caracteres, números y símbolos, crea un hash con el mismo algoritmo de cifrado y lo compara con el hash en la base de datos.

Así que la forma de hacerlo es combinar el hash con una sal única. En muchos casos, la fecha y hora actual (hasta milisegundos) que el usuario registra.

Sin embargo, esta sal se almacena en la columna de la base de datos 'salt'.

Así que mi pregunta es, ¿cómo cambia esto el hecho de que si el atacante tiene acceso a la base de datos y tiene el hash creado para la contraseña 'real' y también tiene el hash para la sal, cómo es esto no solo como sujeto a un ataque de arcoiris? Porque, la teoría sería que él intenta cada permutación + el hash de sal y compara el resultado con el hash de la contraseña. Puede tomar un poco más de tiempo, pero no veo cómo es infalible.

Perdona mi ignorancia, solo estoy aprendiendo esto y esto nunca tuvo mucho sentido para mí.

Fuente

2010-10-23 marcamillion

posible duplicado de [¿Dónde almacena sus cadenas de sal?] (Http://stackoverflow.com/questions/1219899/where-do-you-store-your-salt-strings) – blowdart

No. No estoy defendiendo o preguntando si tiene más sentido almacenar la sal en otro lugar que el db. Estoy tratando de explorar la idea de cómo una sal es realmente más segura, en una era en la que los recursos informáticos son tan baratos. – marcamillion

SHA-2 es un algoritmo hash. Hashing es un concepto diferente al cifrado. – wulfgarpro

La principal ventaja de una sal (elegida al azar) es que incluso si dos personas usan la misma contraseña, el hash será diferente porque las sales serán diferentes. Esto significa que el atacante no puede calcular previamente los valores hash de contraseñas comunes porque hay demasiados valores de sal diferentes.

Tenga en cuenta que la sal no debe mantenerse en secreto; solo tiene que ser lo suficientemente grande (64 bits, por ejemplo) y lo suficientemente aleatorio como para que dos personas que usan la misma contraseña tengan una posibilidad muy pequeña de usar también la misma sal. (Podrías, si quisieras, comprobar que la sal fuera única)

Fuente

2010-10-23 20:09:23

Oh, está bien. Entonces la idea es que el atacante no hará un ataque de fuerza bruta (comparando la cuerda salada con el hash pw en el DB) porque lleva demasiado, siempre que el hash salt + pw sea lo suficientemente largo (64 bits a pieza)? Si ese es el caso, ¿no tiene mucho sentido en un día y una edad en que los recursos de computación son cada vez más baratos? Por ejemplo, si un atacante tiene acceso a una botnet de 1 millón de computadoras, ¿por qué no podría escribir una secuencia de comandos para hacer esa comparación de fuerza bruta de cada sal con esas millones de máquinas? – marcamillion

Lleva un tiempo bastante largo aplicar fuerza bruta a la fuerza bruta, e incluso si fuera tan fácil como usted está implicando, todavía podría detener a cualquiera sin un millón de botnets de computadoras a su disposición. – ceejayoz

El objetivo es hacer que sea más difícil descifrar contraseñas que otros métodos de ataque. Si el atacante puede leer la base de datos Y tiene suficiente tiempo de computación disponible para construir una tabla arcoiris para el valor de sal para cada cuenta que el atacante quiere, entonces usted o el atacante calcularon mal el riesgo/valor de irrumpir en su sitio. – Slartibartfast

El atacante no puede hacer un ataque de arcoiris y tiene fuerza bruta que es mucho menos eficiente.

Fuente

2010-10-23 20:09:44

Ver la respuesta aceptada a esta pregunta; Where do you store your salt strings?

Explica cómo el hash frustra los ataques de arcoíris.

Fuente

2010-10-23 20:13:36 nickd

Esto explica la idea detrás de la tabla del arcoíris para mí (es decir, va en contra de la idea de hacer una fuerza bruta str8 de cada permutación haciendo cálculos previos/conjeturas en forma de una tabla del arco iris).Pero todavía no entiendo por qué es tan difícil de descifrar en un día y edad cuando los recursos informáticos son tan baratos. – marcamillion

No es imposible, con tiempo suficiente puedes forzar brutalmente un hash salado. Esta es la razón por la que todavía intenta mantener su base de datos privada :) Y, por supuesto, no es la única consideración. Otros incluyen el uso de un buen algoritmo de hashing, muchos de ellos se centran en ser rápidos al hash, que es lo contrario de lo que se quiere cuando se utilizan contraseñas. – Nick

@Nick. Bastante. Muchos estándares sugieren hashing contraseñas saladas varias veces (generalmente> 1000) porque el cálculo adicional requerido no dificulta en gran medida la comprobación de una contraseña, pero sí obstaculiza significativamente los ataques de fuerza bruta. – dajames

En primer lugar, lo que has descrito no es un ataque de arco iris, es un ataque de diccionario.

En segundo lugar, el principal objetivo del uso de sal es que simplemente hace la vida más difícil para el atacante. Por ejemplo, si agrega una sal de 32 bits a cada frase de contraseña, el atacante tiene que ajustar y volver a hash cada entrada en el diccionario ~ 4 mil millones de veces, y almacenar los resultados de todos de aquellos para tener un éxito ataque.

Para tener alguna esperanza de ser efectivo, un diccionario necesita incluir algo así como un millón de entradas (y un millón de resultados coincidentes). Mencionaste SHA-1, así que vamos a usar eso para nuestro ejemplo. Produce un resultado de 20 bytes (160 bits). Adivinemos que una entrada promedio es algo así como 8 caracteres de largo. Eso significa que un diccionario debe ser algo así como 28 megabytes. Con una sal de 32 bits, sin embargo, tanto el tamaño como el tiempo para producir el diccionario se multiplican por 2 -1.

Al igual que una aproximación aproximada extremadamente, digamos que producir un diccionario (sin sal) llevó una hora. Hacer lo mismo con una sal de 32 bits tomaría 2 -1 horas, lo que equivale a alrededor de 15 años. No hay muchas personas dispuestas a pasar ese tiempo en un ataque.

Como mencionas las tablas del arcoíris, añadiré que, por lo general, son incluso más grandes y más lentas para empezar. Una tabla rainbow típica llenará fácilmente un DVD y multiplicar eso por 2 -1 da un número lo suficientemente grande como para que el almacenamiento también se convierta en un problema serio (como en, eso es más que todo el almacenamiento construido en toda la historia de las computadoras , al menos en el planeta tierra).

Fuente

2010-10-23 20:31:35

Ok, es suficiente. Tu matemática tiene sentido. Puedo ver cómo este ataque no es infalible, pero es suficiente para disuadir a los atacantes "indeterminados". Pero es justo decir que el uso de una sal hash + aún se puede romper, ¿verdad? Por ejemplo, esos 15 años se pueden reducir de manera significativa con 100.000 computadoras haciendo el cálculo o incluso 1 millón. Si supone que el atacante tiene recursos de computación esencialmente ilimitados para resolver el problema (por ejemplo, hackeó Google y tiene hachazos para todos los servidores de Google, es exagerado pero solo ilustra un punto), entonces hacer un ataque de diccionario tiene sentido, ¿no? – marcamillion

2^32-1 bits = 4,294,967,295 bits = 536MBytes. A menos que quisieras decir 2^32-1 * 32 bits, entonces eso no es mucho almacenamiento. Incluso entonces, 2^32-1 * 32 = 17.179GB. – marcamillion

@marcmillion: también debe combinar los resultados, por lo que incluso con muchos servidores, también necesita buena comunicación, coordinación, etc. para hacerlo (pero sí, finalmente es posible). No estoy seguro de a dónde intenta llegar con sus cálculos. Cada bit que agrega a la tecla duplica el tamaño del diccionario. –

¿Cómo se usa una sal para hacer una contraseña más segura si se almacena en la base de datos?

Respuesta

Cuestiones relacionadas