¿Se almacenan las cadenas Salt por aplicación? [duplicar]

Question

¿Se almacenan las cadenas Salt por aplicación? [duplicar]

#1 de ISMSDEV (0 votos)
#2 de zzarzzur (0 votos)
#3 de ste-fu (0 votos)

0

1) Como el almacenamiento de contraseñas en texto sin formato en las bases de datos no es seguro y por lo tanto no es una buena práctica.
contraseña almacenada en db="abcde" (texto sin formato)
2) Para evitar esto, las contraseñas se almacenan después de ser procesadas utilizando algunas técnicas de hash confiables como SHA256 o SHA 512, etc. 3) Pero como las contraseñas con hash son vulnerables a los ataques de tabla arco iris o ataques de diccionario, se aplica una nueva técnica de salado. Aquí se agrega una sal (alguna cadena) (normalmente con un prefijo o un sufijo) a la contraseña y luego la contraseña resultante + sal se rellena y se almacena en db.
contraseña + sal="abcde" + "catsarecool" y < br> contraseña almacenada en db = SHA256 ("abcdecatsarecool") = 8A85335AB6B09405FF34DCC146A0B690A3BFA834B8C53EBAD77F64C653A89F82

Ahora puedo explicar / preguntar sobre lo que quiero confirmar y las preocupaciones que tengo -
1) al usar salting (3), supongo que la cadena de sal también debe almacenarse en la base de datos. Por favor confirme?
2) Si la cadena de sal debe almacenarse en la base de datos, ¿cuál es la mejor práctica? Usar una sal común para todos los usuarios de la aplicación o una sal por usuario.
3) a) El objetivo principal del hash era que cualquier atacante que obtenga el volcado de DB pueda ver las contraseñas en texto sin formato, lo que es menos seguro que cuando se utiliza el hash.
b) Y el propósito de la salazón es hacer que este trabajo sea más difícil al hacer imposibles los ataques de tabla arco iris o diccionario, ya que el atacante también tendrá que hacer una conjetura de "sal" junto con la contraseña. Pero si un atacante puede obtener un volcado de base de datos de alguna manera, entonces el atacante también tendría las "sales" que, si se almacenan en db, se almacenan como texto simple. Así que ahora que el atacante sabe la "sal", no es su tarea de descifrar la contraseña tan difícil como lo era cuando estaba tratando de descifrar las contraseñas de hash.

No soy un experto en seguridad, pero soy consciente de que para almacenar contraseñas, las técnicas más lentas como bcrypt o scrypt o PBKDF2 serán más apropiadas. Los comentarios sobre estas u otras técnicas que son mejores para almacenar contraseñas son bienvenidos. Pero estoy preocupado por el escenario anterior para el propósito de aprendizaje? Así que amablemente comparte tus pensamientos.

passwords salt password-cracking scrypt sha2

pregunta joveny 22.07.2017 - 07:03

fuente

3 respuestas

Lea otras preguntas en las etiquetas passwords salt password-cracking scrypt sha2

¿Cómo configurar un servidor para archivos? [cerrado] ¿Alguna razón de seguridad para mantener PHP short_open_tag desactivado?

score 0 · Answer 1

Tienes varias preguntas en una, así que responderé lo que creo que es tu pregunta principal.

Utilice una sal por contraseña por usuario. Esto detiene los ataques de la tabla arco iris, ya que un atacante ahora necesita una tabla arco iris para cada contraseña posible con cada sal que estés usando. Para ellos computar esto sería inviable. Recomendaría usar PBDKF # 2 o bcrypt o una de las otras funciones de derivación de clave basadas en contraseña (PBKDF). En esta época, el hashing, incluso con sal, se ve ahora como una solución más débil que usar un buen PBKDF.

score 0 · Answer 2

El propósito de una sal es evitar el uso de una mesa de arco iris. Los piratas informáticos suelen salir de archivos grandes que contienen hash precomputado, lo utilizan para acelerar el descifrado de contraseñas.

Al agregar un salt a su contraseña, esencialmente está convirtiendo "contraseña" en "contraseñaGSVKELWO". Prevenir el uso de una tabla de arco iris y aumentar aún más la complejidad de la aplicación de la contraseña. Sin embargo, para que pueda verificar el hash, necesita saber la sal que utilizó para crearlo. Como tal, se acepta que almacene el salt junto con el hash de la contraseña y que lo use para verificar la contraseña de los usuarios cuando inician sesión. Ahora porque está haciendo un seguimiento de la sal, definitivamente debe seguir adelante y usar unos únicos para cada usuario.

Algoritmos como bcrypt tienen un parámetro llamado trabajo, que determina qué tan intensivo es el CPU. Un valor de trabajo alto puede agregar uno o dos segundos para iniciar sesión, pero cuando un atacante intenta descifrarlo, se volverá exponencialmente más lento.

El uso de estas técnicas es aceptable para el aprendizaje, pero no para el desarrollo. Utilice una biblioteca ampliamente conocida y aceptada para manejar la comprobación y el control de su contraseña, para asegurarse de que está protegido contra todas las vías de ataque.

score 0 · Answer 3

Ok muchas preguntas, aquí vamos.

1) Sí, la sal debe almacenarse en la base de datos. De lo contrario no será posible verificar el hash. Normalmente, la sal como una matriz de bytes se añade o añade al hash y luego se codifica en base 64 y se almacena como una cadena.

2) Sí, una sal por usuario es la norma, almacenada como anteriormente.

3) a) Sí, absolutamente eso. b) Todavía es algo más difícil. Una sal única por usuario significa que dos usuarios con la misma contraseña tienen hashes diferentes. Con una sal fija serán las mismas. Esto significa que los hashes se pueden romper mediante algún tipo de análisis de frecuencia.

La mejor práctica actual es no usar un solo hash usando algo como sha256 ya que el algoritmo es rápido y eso hace que la fuerza bruta sea más rápida. Por lo general, esto se logra realizando muchas rondas (quizás 10000) de hash o algún otro método para ajustar la cantidad de trabajo requerido. Como usuario, puede esperar un segundo para que se verifique el hash al iniciar sesión. Como atacante aumenta enormemente el tiempo empleado