¿Es la distribución de un hash realmente tan segura como implica el conocimiento común?

Es fundamentalmente correcto que solo está haciendo que la contraseña sea más larga, pero hay algunas cosas adicionales que agrega. Además, la contraseña promedio no es tan larga ni segura y la extensión "gratis" rara vez es mala. El salt lo hace para que un atacante no pueda hash "contraseña" una vez y luego buscar a cada usuario que tenga una contraseña de "contraseña".

En su lugar, tendrían que generar hashes de "password03j9834nfp-3028n408" y "passwordn0438wnvas89v5sne" y ... Esto aumenta considerablemente la protección de la identificación de contraseñas inseguras y aún tiene un beneficio positivo para aumentar la dificultad de encontrar contraseñas seguras.

Cuando se equivoca su comprensión es cuando dice "¿No podría un atacante simplemente construir una tabla de arco iris, luego convertir todos los hashes y eliminar la sal?". Hay algunos problemas aquí.

El primero es el de las colisiones. No se garantiza que una tabla arco iris produzca la entrada original, solo está interesada en producir una entrada AN que produzca la salida deseada. Dado que la sal se agregará a lo que ingrese el usuario, el atacante debe encontrar la entrada exacta que se usó para el hash.

Dado que se debe encontrar la entrada exacta, se pierde el beneficio de una tabla de arco iris para aprovechar las colisiones. Además, el tamaño requerido para forzar la fuerza bruta de todas las sales posibles sería demasiado grande como para que lo pueda sostener cualquier atacante.

Tampoco puedes simplemente eliminar la sal de un hash sin descubrir cuál fue la entrada original. Tendrías que buscar algún valor que termine en la sal que corresponda al hash dado. Esto requiere que se produzca una tabla de arco iris separada para cada valor de sal en el DB y esto anula la capacidad de realizar un cálculo previo ya que no es factible hacer una tabla de arco iris para cada sal posible.

Tienes una idea errónea fundamental de cómo funcionan las tablas de arco iris.

Un atacante anterior construye una tabla arco iris o una tabla hash para un ataque. Supongamos que construyo una tabla hash que contiene todos los hashes de cadenas por debajo de 7 caracteres para MD5 . Si comprometo su base de datos y obtengo una lista de hashes, todo lo que tengo que hacer es buscar el hash en la tabla para obtener su contraseña.

Con un salt, no puede generar una tabla de arco iris para un algoritmo específico anterior a un ataque. Una sal no debe ser secreta, la almacena junto con el hash en su base de datos.

x = hash(salt+password) Luego lo almacenará en su base de datos en el formato de salt+x Esto hace que las tablas de arco iris y las tablas hash sean inútiles.

Como de costumbre, no hagas tu propio rollo, usa bcrypt , scrypt o pbkdf2 que se encarga de todos los detalles, incluida la salazón para ti. Consulte ¿Cómo hash seguro de contraseñas?

Una rainbow table es una Optimización para revertir hashes por fuerza bruta. Funciona mediante un compromiso: haces una gran cantidad de precomputación para construir una gran estructura de datos, y luego puedes romper muchos hashes rápidamente.

Una tabla de arco iris solo ayuda a los hashes de grietas en el espacio de búsqueda que cubre. Concretamente, las tablas de arco iris están construidas para plaintexts hechos de caracteres imprimibles y [hasta cierta longitud. El principio básico de agregar una sal es que el texto sin formato que contiene un hash contiene tanto la contraseña como la sal; con el agregado de sal, el espacio de búsqueda se convierte en demasiado grande para construir una tabla de arco iris .

Por lo tanto, al agregar un salt a la contraseña, no hay forma de amortizar el costo de un ataque de fuerza bruta sobre muchas grietas. El atacante tiene que hacer todo el trabajo para cada hash, comenzando solo cuando conoce la sal.

Dado un hash y una sal, no hay manera de "eliminar la sal". Esta es una propiedad básica de una función de hash: incluso si sabe que dos cadenas están relacionadas (por ejemplo, sabe que la contraseña es una subcadena de contraseña + sal), no le ayuda a encontrar el hash (contraseña) conociendo el hash (contraseña + sal). No hay necesidad de ocultar la sal del atacante : debe ser único (y no se deriva desde la contraseña ) pero no necesita ser más secreto que el hash. (Puede agregar una sal secreta adicional, que se llama pimienta , pero solo es útil en un conjunto limitado de circunstancias.)

Saltar el hash es solo la mitad de la batalla. Otra parte de las contraseñas de hash de forma segura es que la función de hash debe ser lenta, ya que afecta más al cracker que al verificador. No haga su propia , use un método que haya sido revisado por expertos. Utilice bcrypt o PBKDF2 o scrypt . La implementación del almacenamiento de contraseñas no debe implicar realizar ninguna criptografía usted mismo, llame a una función de biblioteca.

Para todo lo que quería saber sobre contraseñas de hash, todo lo que no quería saber sobre contraseñas de hash y todo lo que ni siquiera sabía que pudiera saber sobre contraseñas de hash, lea ¿Cómo hacer hash de forma segura las contraseñas?

Una sal única resuelve un problema: cada cuenta no puede ser atacada simultáneamente en un intento de fuerza bruta gigante.

Supongamos que ha intentado construir una tabla de arco iris con todas las contraseñas ASCII imprimibles que tenían 8 caracteres de longitud ¹ . Eso es 96 ⁸ ~ 7.2 millones de billones (7.2 x 10 ¹⁵ ) posibilidades. Si tenía una GPU que genera contraseñas a un billón por segundo, tardará aproximadamente un mes en descifrarlas (y a 200W a $ 0.10 por kWhr son aproximadamente $ 200 en promedio; ~ $ 400 en el peor de los casos para su factura eléctrica).

Entonces, averigua los hashes de cada cuenta en linkedin a partir de algún tipo de inyección SQL o de encontrar un disco duro con una copia de seguridad antigua. Tienes hashes de un millón de usuarios. Ahora, si son hashes sin sal, puede romper la gran mayoría de estos hashes en dos meses con una GPU por aproximadamente ~ $ 400 de electricidad. Si todos están salados de manera única y quiere romper todos los millones de ellos, ahora tomará $ 400 millones de dólares en electricidad, ya que cada sal única tiene que tener su propio ataque independiente. Ahora, antes de que digas, construiré una tabla de arco iris más grande que incluya las sales, y me daré cuenta de que, como mínimo, una sal típica tiene 5 caracteres hexadecimales (16 ** 5), lo que significa que llevará un millón de veces más crear tu arco iris. tabla (por ejemplo, deberá gastar $ 400 millones en la electricidad para generarla).

Ahora agregue el fortalecimiento de teclas donde, en lugar de hacer un hash una vez, repita el proceso N veces (por ejemplo, una función de hash iterada tres veces sería: hash(salt+hash(salt+hash(salt+pw))) ). Ahora, en lugar de poder romper mil millones de hashes por segundo, pueden romper mil millones de hashes / N por segundo, por lo que todos los ataques serán N veces más caros. (Un N típico es 5000; por lo tanto, para romper un solo hash se necesitarían alrededor de $ 2 millones en electricidad; el problema con el N súper grande es que hay más recursos computacionales en sus servidores para verificar los intentos de contraseña).

¹ : esta no es la forma más efectiva de descifrar contraseñas. Las listas de diccionarios de millones de contraseñas utilizadas anteriormente son mucho más efectivas, ya que muchas contraseñas son bastante débiles. No recomiendo a las personas que generen contraseñas por sí mismas (por lo general una entropía muy baja) o que reutilicen las contraseñas. Use un servicio como keepassx que le permita crear contraseñas aleatorias para cada sitio y almacenar en un archivo cifrado. Fortalecimiento de teclas + sal única significa que no es factible intentar romper ninguno de los hashes más simples.

Las tablas de arco iris son tablas hash precomputadas que se usan para descifrar las contraseñas en un tiempo relativamente más rápido porque buscar una tabla es mucho más rápido que calcular un hash.

  

si uno puede encontrar las contraseñas con hash, debería poder encontrar las sales correspondientes

La sal conocida por el atacante no creará un gran problema si el atacante intenta descifrar una contraseña única . La sal dificultará y llevará mucho tiempo descifrar una lista de contraseñas porque para cada contraseña la sal es diferente.

  

¿Pero dónde se almacena la sal? Una sal es simplemente hacer tablas de arco iris "inútiles", ¿no?

La sal se almacena solo en la base de datos y por cada contraseña tiene una sal aleatoria diferente. Sí, la sal hace que sea muy difícil usar una tabla de arco iris. Las tablas de arco iris generalmente se crean utilizando contraseñas comunes que se utilizan. La adición de una sal aleatoria hace que sea muy difícil que se rompa con una tabla de arco iris.

  

¿No podría un atacante simplemente construir una tabla de arco iris, luego convertir todos los hashes y eliminar la sal?

Puede significar que estás construyendo una tabla de arco iris con sales conocidas (antes de llevar a cabo el ataque real) porque no puedes simplemente eliminar una sal del hash. No se recomienda volver a calcular la tabla porque si tiene en cuenta todas las sales conocidas, el tamaño de la tabla también será big.Recuerda el intercambio de espacio / tiempo. Si crea las tablas para una sal a la vez, está gastando demasiada energía. El propósito principal de crear una tabla arco iris es descifrar una lista de contraseñas y no una sola contraseña.

Otra adición de valor muy importante que brinda la salazón es que no hay dos usuarios que terminen con un hash de contraseña idéntico porque las sales serán diferentes. Imagine que un atacante puede descifrar una de las contraseñas y si no se usan las sales, el atacante simplemente tiene que hacer una búsqueda para averiguar qué otros usuarios están usando la misma contraseña.

En primer lugar, ¿por qué está implementando un código criptográfico de bajo nivel para una página web? Usted pensaría que este es un problema resuelto: utiliza un marco que utiliza bibliotecas.

En segundo lugar, el hash protege las contraseñas en caso de que se filtren. Su sitio no proporciona acceso a la base de datos de contraseñas, por lo que, idealmente, esta situación no debería surgir. Las sales ayudan a defender la base de datos de contraseñas en su totalidad en ese evento.

Si el atacante está enfocado en una sola contraseña de esa base de datos, entonces no hay mucha diferencia. Solo dificulta el trabajo en el sentido de que el atacante no puede simplemente recuperar la contraseña de una tabla de arco iris buscando el hash. La fuerza bruta de una contraseña con un salt solo se ralentiza ligeramente porque se procesan unos pocos bytes más, lo que cuesta unos pocos ciclos de máquina más en las rondas de hashing.

Érase una vez, los sistemas Unix que proporcionan acceso público (como los sistemas de campus para estudiantes) tenían sus contraseñas descifradas a la izquierda y a la derecha. Hubo varias razones por las que esto fue fácil, pero el problema principal fue simple: la información confidencial de hash de la contraseña se mantuvo en el mismo archivo que los otros campos de información sobre un usuario, y ese archivo, /etc/passwd fue legible en todo el mundo. La solución es colocar la información confidencial en un archivo separado, /etc/shadow . Presto: eso termina con el descifrado de contraseñas por parte de los chavales de script que tienen cuentas legítimas y sin privilegios en el sistema.

Del mismo modo, nadie será brutal forzando tus contraseñas a menos que dejes que se filtren. Si se filtran y alguien está detrás de la contraseña de un usuario en particular, hay poco que se pueda hacer para detenerlos.

Los usuarios que usan las mismas contraseñas en diferentes sistemas y no las cambian durante años y Los años siempre van a ser vulnerables. Puedes saltearlo, salpimentarlo y agregar ketchup; no hará una diferencia.

Las sales disuaden a alguien que quiere descifrar la base de datos de contraseñas como un todo y reúnen tantas contraseñas diferentes como sea posible. Las sales significan que cada contraseña debe ser forzada de manera bruta individualmente en lugar de solo recuperarse de tablas precalculadas. Si una sal tiene N bits, entonces, al menos idealmente, la base de datos de la tabla del arco iris del atacante debe ser 2 ^ N veces más grande. Una sal de 32 bits significa que necesita una base de datos de tabla arco iris cuatro mil millones de veces más grande para simplemente buscar contraseñas.

Si su sitio solo tiene 20 usuarios, por supuesto, solo hay hasta 20 sales diferentes. Entonces, lo que hará un atacante es tomar el diccionario de contraseñas y hacer hash en cada entrada de 20 maneras diferentes con esas sales.

Por lo tanto, las sales no solo protegen su base de datos contra la búsqueda en la tabla del arco iris, sino que también la protegen del craqueo de fuerza bruta en un factor de N, donde N es el número de usuarios. Para las contraseñas de fuerza bruta N, el atacante tiene que hacer N veces el trabajo como fuerza bruta. (Suponiendo que la sal sea lo suficientemente amplia: al menos tan grande como el logaritmo en base 2 de N. Si una sal es solo de 12 bits, digamos, solo puede haber 4096 sales diferentes, sin importar cuántos usuarios haya).

Sin sales, esto no es cierto. Brute forzar cualquier cantidad de contraseñas al mismo tiempo es tan fácil como brute forzar una, por lo que cuantos más usuarios haya, mayor será la recompensa por esfuerzo.

Hay un par de factores relacionados con la salazón, y te estás perdiendo (al menos) uno de esos.

• Hacen las tablas del arco iris inútiles. Si alguien busca en su base de datos de contraseñas y ve que la contraseña es "5f4dcc3b5aa765d61d8327deb882cf99," ni siquiera necesitan construir una "tabla de arco iris", solo pueden buscar ese valor en Google y Google les dirá que es el hash md5 de " contraseña". Si las contraseñas están escritas con hash antes de colocarlas en su base de datos, el mecanismo de búsqueda de la "tabla de arco iris" será inútil. No es necesario almacenar la sal en la base de datos para que las mesas de arco iris sean inútiles. Su sal solo puede ser siempre "xxxx" o cualquier otra cadena arbitraria. Si buscas en Google para 6a316e1fdac8a61d9c7a2ed1cba4a804 (el hash md5 de "xxxxpassword"), no obtienes resultados.

• Si se hace correctamente, la sal generalmente significa que un intruso necesita ambos su base de datos y su código para descifrar sus contraseñas. Podría haber escrito su contraseña como "xxxx" + contraseña o pw.substring (0,2) + "xxxx" + pw.substring (2). El atacante no sabe cómo ingresó sus contraseñas a menos que también haya robado su código. Su servidor web a menudo no se ejecuta en el mismo cuadro que su base de datos, y con los lenguajes de programación compilados, su código puede que tampoco esté disponible en su servidor web. Independientemente de las sales que almacene en su base de datos, recomendaría tener una sal larga, arbitraria y fija almacenada fuera de la base de datos que además está concatenada a la contraseña antes del hashing.

• Las sales únicas hacen que las grietas sean más caras. Como lo señaló otra persona, si hash cada palabra del diccionario con un salt estático ("xxxx"), entonces puedes escanear toda la base de datos de contraseñas en busca de "6a316e1fdac8a61d9c7a2ed1cba4a804" buscando la contraseña de "contraseña". Si cada fila usa un salt diferente, entonces tiene que realizar N hashes solo para descubrir si uno de los N usuarios tiene la contraseña "password".

• En el segundo punto, tenga cuidado de solo usar una sal simple fija única sin ninguna otra. Un cracker podría probar el hash de cadenas arbitrarias + "contraseña" hasta encontrar a alguien cuya contraseña fuera "contraseña" y luego esencialmente hubiera descifrado su sal. En cualquier base de datos de contraseñas grande, es probable que al menos un usuario tenga una contraseña trivial como "contraseña".

Veo una mesa de arco iris que aún funciona aquí, aunque con un poco más de trabajo.

si x es el valor de hash para contraseña + sal y dado que todos pueden conocerlo ya que está almacenado en la base de datos en los archivos de la aplicación, aún puedo usar una tabla de arco iris

elija su tabla de arco iris, agregue nuevas columnas, es decir, hashed_password_Salt para todos los valores de hash, luego ejecute una actualización para la columna con el resultado de x = hash (contraseña + sal) ya que la columna de cadenas de contraseña comunes que ya tiene

a continuación, se actualizará la tabla de arco iris para manejar el descifrado de contraseñas utilizando el ataque de diccionario

Sombody puede corregirme si esto no es una forma viable