¿Para sal, o no para sal? [duplicar]

Las sales no ayudan a evitar que alguien descifre una contraseña en particular. Ayudan a evitar que alguien pueda descifrar muchas contraseñas a la vez utilizando una tabla de arco iris.

Supongamos que tiene los siguientes usuarios en su sitio (la contraseña no se almacenaría en la base de datos, solo la versión con hash).

USER         PASSWORD    HASHED PASSWORD   
========================================  
hamfist      god         de898928393a893
bttltoad     god         de898928393a893
woob         god         de898928393a893
marco-fiset  mypass1     1238ffff2342399
dean         password2   a44ca77446ff449

Si alguien programara previamente los hashes para un montón de contraseñas y almacenara esto en la memoria (una tabla de arco iris), sería trivial para ellos verificar si de898928393a893 existía en la lista de contraseñas. Entonces sabrían que a todas estas cuentas de usuarios se podría acceder con la contraseña, god . En muy poco tiempo, tendrían acceso a las cuentas de todos con una contraseña simple que existe en su tabla de arco iris (y en cualquier otro lugar en la web esa persona usa el mismo combo de correo electrónico / contraseña).

Ahora, si agrega un salt al azar, todos los que tengan la misma contraseña terminarán con diferentes hashes:

USER         PASSWORD    SALT   HASHED PASSWORD   
===============================================  
hamfist      god         ae#o   abf4388ff343401
bttltoad     god         cdo@   29292d919100001
woob         god         !doe   3902dda99210099
marco-fiset  mypass1     12uo   aaffff121bcce13
dean         password2   TEe9   b44ca7743324234

Ahora, una mesa de arco iris no ayuda mucho. En lugar de simplemente necesitar el hash para god , por ejemplo, necesitaría calcular previamente el hash para god + <all_potential_salts> . Tipo de límites que puedes almacenar en la memoria.

Sin embargo, si alguien quiere obtener hamfist específicamente, tiene la sal ya que está almacenada en la base de datos, por lo que no va a ralentizar el intento de craqueo.

Sí y no.

Salt lo protege contra alguien que obtiene su base de datos y deduce las contraseñas reales a pesar de que tienen un hash. (Si alguien roba toda su base de datos, es probable que también hayan obtenido los datos de usuario que las contraseñas debían proteger en primer lugar, pero supongamos que las contraseñas son incluso más valiosas que el uso de datos, porque muchas personas usan sus contraseñas en varios sitios, lo que también se vería comprometido.) por lo tanto, tanto el hashing como el salado es una práctica estándar para proteger de manera óptima a sus usuarios.

Sin embargo, Salt no lo protege de las personas que eligen "password123" como contraseña, y un atacante simplemente prueba contraseñas comunes. Nada puede protegerlo de eso: si el usuario puede ingresar su contraseña limitada y obtener acceso, también lo puede hacer un atacante (el sistema no sabe quién está en el otro extremo de la línea, que es todo el punto de las contraseñas, para empezar). ).

Para una buena seguridad, tanto el proveedor como el usuario deben actuar de manera mínimamente competente, uno de los dos no es suficiente.

La sal no está ahí para prevenir eso. Las sales están ahí para prevenir ataques usando tablas de arco iris, que básicamente son listas de hashes y sus contraseñas. Esto es cuando un ataque ya tiene su contraseña hash.

Además de las tablas de arco iris, las sales impiden que alguien con acceso a su base de datos sepa si un par de usuarios dado comparte la misma contraseña.

Hay otra sección del artículo que responde a tu pregunta:

  

    

Dijiste que las sales no son útiles, pero ¿qué pasa con las tablas de arco iris? ¿Por qué sugieres que las personas no usen sales?

  

     

Como el Provos & El artículo de Mazières describe, bcrypt tiene sales incorporadas para evitar ataques a la mesa del arco iris. Así que no estoy diciendo que las sales no tengan un propósito, estoy diciendo que no evitan los ataques de diccionario o fuerza bruta (que no lo hacen). [énfasis añadido]

Como dijeron los demás, simplemente te protegen de las tablas de arco iris y tal vez diferencien los mismos hashes de contraseña entre diferentes sitios. No debe hacer ningún esfuerzo para hacer que la sal sea secreta (muchos defienden erróneamente ponerlos en un servidor diferente, etc.), mantener la sal junto con los hashes de contraseña estaría bien. Todos sus esfuerzos deben concentrarse en garantizar la ubicación de los hashes de contraseña.

Si entendí correctamente, la cita dice "No afecta a la rapidez con la que un atacante puede probar una contraseña candidata, dado el hash y la sal de su base de datos", y "la sal de su base de datos" es la parte principal aquí .

Si almacena la sal en la base de datos, y un atacante tiene acceso a esa tabla de la base de datos donde encuentra el hash y la sal, puede atacar con fuerza bruta esos hashes usando la sal, por lo que usar o no usar una sal es lo mismo (excepto por la desaceleración del atacante debido al aumento del trabajo de hash, que es un factor, pero no tan importante).

Visto de esta manera, tiene sentido, si el atacante tiene "sales de tu base de datos".