¿Cómo están seguras las sales en la base de datos? [duplicar]

0

He leído muchas y muchas de este tipo de preguntas en la comunidad de la pila de seguridad antes de hacer esta pregunta, pero una cosa que me hizo enojar por las sales y guardarlas en la base de datos es esto ... Me pondré en el Posición del atacante.

Si hackeo una base de datos y encuentro una tabla llamada por ejemplo (usuarios) y veo un campo llamado (sal) y otro (contraseña o hash) puedo, fácilmente, sin esfuerzo, saber que se usa la sal Para producir este hash o esta contraseña. Así que, por ejemplo, tomaré la sal del primer registro y haré un diccionario de todos los hashes de todas las palabras en inglés (tabla del arco iris) y luego usaré la sal que obtuve del primer registro y trataré de hacer hash con cada hash. entré en la mesa del arco iris y obtendré el hachís salado fácilmente al final ... así que, por favor, ¿por qué todo el mundo dice SO o Internet dice que poner la sal en la base de datos es una buena práctica o es seguro? .. No lo veo como seguro y, por favor, corríjame si me equivoco ... gracias de antemano.

He pospuesto mi proyecto debido a este problema.

    
pregunta ahmed nader 24.06.2016 - 21:57
fuente

4 respuestas

3

El propósito de la distribución es que no se puede construir una tabla de arco iris para obtener varias contraseñas a la vez.

Sin salado : un atacante podría buscar en el Internet tablas de arco iris precalculadas y encontrar las contraseñas sin ningún esfuerzo.

Con una sal constante : el atacante debe crear una tabla de arco iris para esta sal específica, y luego puede obtener todas las contraseñas con esta única tabla de arco iris.

Con un salt único : si cada contraseña obtiene su propio salt, el atacante debe crear una tabla de arco iris para cada contraseña. En este caso, la fuerza bruta es más rápida, no tiene sentido terminar la tabla del arco iris después de encontrar una coincidencia, porque de todos modos no se pueden obtener otras contraseñas.

Así que ya ves, incluso si se conoce la sal, cumple su propósito. Si desea agregar un secreto al proceso, debe utilizar una clave del lado del servidor y cifrar los hashes de contraseña ya calculados. No mezcle la sal con otras medidas de seguridad.

    
respondido por el martinstoeckli 24.06.2016 - 22:07
fuente
0

Usted respondió su pregunta, simplemente no la vio.

  

¿Por qué todas las personas dicen en SO o Internet de todos modos que poner la sal en   La base de datos es buena práctica o segura

La respuesta es:

  

si hackeo una base de datos (...) tomaré la sal de la primera   grabar, por ejemplo, y hacer un diccionario de todos los hashes de todos los ingleses   Palabras (tabla del arco iris) y luego hago otro paso que está usando   la sal que obtuve del primer registro y trate de mezclarla con cada   el hachís me metí en la mesa del arco iris y obtendré el hachís salado fácilmente   al final

Un hash sin sal ya tendrá tablas de arco iris disponibles. Si usas sal, necesitarás construirla. Lo único en lo que te equivocas es cuando dices que es fácil. No es fácil, en absoluto, porque necesitará una nueva "mesa de arco iris" para el picadillo salado. Se necesita mucha energía y tiempo en la computadora, y esa es la protección que está agregando.

Nota: un hash salado no está cambiando el hash de la contraseña con un salt. Se parece más a mezclar (o concatenar) la contraseña original y la sal y luego trocearla.

    
respondido por el CristianTM 24.06.2016 - 22:06
fuente
0

Otros han aclarado el propósito de Salt, que es requerir un proceso separado de fuerza bruta por usuario para romper, lo que llevaría mucho más tiempo que un solo proceso de fuerza bruta para encontrar coincidencias para cada usuario a la vez. La sal no es necesaria para ser secreta, sino única.

Una buena manera de mejorar esto es incluir Pepper, que es un secreto. Pepper es solo una cadena aleatoria para su aplicación, ya sea almacenada en el código fuente o en un archivo separado, pero no en la base de datos SQL.

El Pepper secreto se combina con la Sal antes de generar el Hash. De esta manera, si el atacante utiliza la inyección SQL (para acceder a Hash + Salt) y no puede violar su sistema de archivos (donde está almacenado el Pepper), no podrá hacer crack.

Y, por supuesto, también hay formas de limitar el impacto de la inyección SQL.

    
respondido por el George Bailey 24.06.2016 - 22:17
fuente
0

La sal tiene para ser almacenada en un lugar al que se pueda acceder fácilmente con un ID de usuario. Eso significa una tabla de base de datos. El pirata informático que puede obtener las contraseñas con hash puede obtener las sales de la misma manera, a menudo utilizando la inyección SQL. Como otros ya han escrito, la sal detiene los ataques de precomputación.

Existe un enfoque llamado hash con clave en el que el hash se genera a partir de una concatenación de la contraseña de texto sin formato, la sal (aún almacenada en la base de datos y única por usuario) y una clave secreta . La clave no necesita y no debe almacenarse en la base de datos. Podría almacenarse en el sistema de archivos o compilarse en el programa de inicio de sesión. Eso proporciona una defensa contra la inyección de SQL. Sin embargo, como otros ya han escrito, no hay seguridad absoluta. Si el atacante puede poner en peligro el sistema operativo del servidor o la aplicación de inicio de sesión, entonces la clave está comprometida y su seguridad es brindis. (Pero los ataques de precomputación aún son prevenidos por la sal, incluso para el atacante que tiene acceso a la clave).

    
respondido por el Bob Brown 24.06.2016 - 22:28
fuente

Lea otras preguntas en las etiquetas