contraseña de inicio de sesión del sistema operativo: ¿Cómo funciona?

2

Estoy creando una aplicación para crear una contraseña para un usuario. Aunque estoy un poco desconcertado sobre cómo funciona todo. Es decir, quiero asegurarme de que mi aplicación almacenará el hash correcto para que el usuario pueda iniciar sesión.

Encontré este código:

pwhash=$(echo $password | mkpasswd -s -m sha-512)

Ahora, si ejecuto la misma contraseña, obtengo dos hashes totalmente diferentes:

$ echo 'test' | mkpasswd -s -m sha-512
$6$QRsW.mu9wC$CSvMrGkfU6.lu14.sNRrZ8Kiyi0zUdlcAH1VBBd.LoTZDmehuoGnsaywm/WD.9GARwINQnp3jJzxQHWlCk3RI0
$ echo 'test' | mkpasswd -s -m sha-512
$6$rN7ishjxd89AjMS$HpN53OoL3m81rPyrKFgpm2Nm2YWJ96nP4gNLu4GO0Jjy9K6lVhB6v7c0L7/998h74oTMGFzLK6w4zku7U3soW0

Así que esto me muestra lo poco que sé. Si la misma contraseña genera dos hashes diferentes, ¿cómo puede saber el sistema operativo que ingresé la contraseña correcta en la pantalla de inicio de sesión? ¿Con qué comparará el hash de contraseña introducido?

También un poco sobre la sal ... se supone que la sal siempre es diferente, así que, ¿cómo puede el sistema operativo saber qué sal usar para la contraseña en cada intento de inicio de sesión?

    
pregunta Johan Hanssen Seferidis 28.08.2015 - 12:32
fuente

1 respuesta

1

Obtienes diferentes valores porque se usan diferentes sales. La sal es el segundo campo en la contraseña con hash.

Existen grandes tablas de arco iris que hacen que la búsqueda de hashes de contraseñas comunes sea muy barata. El punto de sal es aumentar dramáticamente el costo de calcular previamente los hashes para todas las contraseñas de uso común. Así que la sal básicamente hace que una contraseña sea poco común. Es decir, hace que una contraseña sea tan larga y aleatoria que no sea factible precalcular el hash para todas las contraseñas comunes para todas las sales posibles .

Dado que el objetivo de Salt es prevenir los ataques exitosos de precálculo, no es necesario que sea un secreto, solo debe ser largo y aleatorio. Esto permite que la sal se almacene en texto sin cifrar junto con cada contraseña hash. Esto es afortunado ya que se necesita el salt para validar la contraseña cuando el usuario se autentica.

Un ejemplo de una implementación incorrecta de salt sería usar un solo byte. En ese escenario, un atacante podría precalcular todos los hashes para contraseñas comunes para las 256 sales posibles. Eso es caro pero no lo suficientemente caro. Esa sal no es lo suficientemente grande.

Otro ejemplo de mis-salating es usar el mismo sal en cada contraseña. Eso permite a un atacante precalcular una sola tabla que contiene los hashes de todas las contraseñas comunes para esa única sal. Esto sería caro pero mucho más barato que tener que crear una tabla para cada contraseña. Es por eso que cada hash de contraseña tiene su propia sal.

Editar: La aplicación de sal no reduce el costo de forzar una contraseña única. Salting solo te obliga a usar contraseñas de fuerza bruta en lugar de precomputar sus hashes. Usted protege contra el uso de fuerza bruta mediante una función hash lenta y la llama muchas veces en una salida sucesiva de sí misma. Por ejemplo, ejecutar bcrypt (que está diseñado para ser lento incluso con una GPU u otro hardware especializado) 1024 veces. Mientras PHP almacena el número de iteraciones en el campo de contraseña , en Linux, el número de iteraciones se configura con la opción PAM 'rounds' . Varios usuarios aquí dicen que el valor predeterminado para su instalación de Debian Linux es de 1000 iteraciones para SHA-512.

Por supuesto, ninguna respuesta sobre contraseñas está completa sin una referencia a esta respuesta , una explicación detallada sobre el Estado del arte para el almacenamiento de contraseñas.

    
respondido por el Neil Smithline 28.08.2015 - 21:58
fuente

Lea otras preguntas en las etiquetas