Hash de contraseña y pez globo [duplicado]

-2

Lo que voy a decir probablemente me hará parecer un idiota, pero es mejor equivocarse y aprender que tener preguntas sin respuesta.

De todos modos, desde que empecé a tratar con contraseñas, me pregunté cuál sería el gran problema de las contraseñas de hash, ya que si alguien se apoderaba de su base de datos, podría encontrar cualquier contraseña sin importar la técnica de hashing utilizada.

Básicamente, el gran defecto de las antiguas funciones de hashing eran las tablas de arco iris, algo que trata el algoritmo actualmente moderno utilizado por PHP en su API de hashing de contraseñas, blowfish. Por supuesto, es bastante complejo y, sin duda, está hecho por gente mucho más inteligente que yo, pero aún así no pude evitar preguntarme si construí mi propia función de hashing que no era vulnerable a las tablas de Rainbow y no almacenaba la sal. en lugares obvios, como columnas adicionales en la base de datos o el uso de información del usuario como nombre o correo electrónico como sal, ¿sería bueno?

Acabo de dedicar unos 5 minutos a preparar este ejemplo para usted, que utiliza, por supuesto, md5, ya que sé que es el desarrollador de PHP más odiado por los críticos :D

function my_password_hash($password){
    $salt = substr(md5(str_shuffle('0123456789abcdef')), 0, 5);

    $hash = substr(md5($password . $salt), 0, -5) . $salt;

    return $hash;
}

function my_password_check($password, $hash){

    $salt = substr($hash, -5);

    return substr(md5($password . $salt), 0, -5) . $salt === $hash;
}

$hash = my_password_hash('qwerty');

var_dump(my_password_check('qwerty', $hash)); // TRUE
var_dump(my_password_check('qwertY', $hash)); // FALSE

Producirá hashes diferentes para la misma entrada cada vez y la sal se mezcla en el hash de salida final, si no sabe explícitamente dónde está, no creo que se pueda encontrar, pero es por eso que Estoy publicando aquí, para averiguar si estoy equivocado.

    
pregunta php_nub_qq 21.02.2015 - 23:42
fuente

2 respuestas

2

Su primera suposición, de que un atacante que obtuvo acceso a la base de datos puede encontrar todas las contraseñas, no es válido. Incluso una sola invocación de MD5 sin sal y sin iteraciones mantendrá las contraseñas más seguras.

Pero solo un porcentaje muy pequeño de usuarios usa una contraseña, que es lo suficientemente fuerte como para mantenerse seguro con un hashing tan simple.

Llamar a las tablas del arco iris como una debilidad no es exactamente correcto. Las tablas arco iris son un método para atacar una debilidad muy específica en algunos hashes de contraseña. Pero hay otras formas de atacar la misma debilidad, incluso algunos métodos que consumen menos memoria y tiempo de CPU que el uso de tablas de arco iris.

Esta debilidad se aborda fácilmente mediante el uso de una sal. Un hash salado derrotará las dos mesas del arco iris y la mayoría de los otros ataques de fuerza bruta. Los hashes de contraseña de última generación han estado utilizando sal durante varias décadas. Incluso el hash de contraseña antiguo (y ahora obsoleto) basado en DES utilizó un salt.

Su enfoque de la salazón comparte una debilidad con las sales utilizadas en las contraseñas basadas en DES, y esa es la longitud de la sal. Se supone que la sal es lo suficientemente larga para que nunca se repita, ni siquiera por coincidencia si todos los sistemas informáticos del mundo utilizan el mismo algoritmo de hashing de contraseña para todas las contraseñas almacenadas durante siglos.

El uso de una sal que sea lo suficientemente larga es prácticamente gratis, por lo que realmente no hay razón para usar una sal con solo 20 bits de entropía.

Agregar sal y hash es una práctica común. En este sentido, su enfoque es prácticamente idéntico a los métodos estándar. Sin embargo, los métodos estándar incluyen una especificación de formato para preservar la compatibilidad en caso de que sea necesario cambiar el algoritmo. Por lo general, también colocan un separador explícito entre sal y hash.

Dejar fuera el separador y fingir que ralentizará a un atacante es seguridad a través de la oscuridad. No funciona.

Es más probable que la oscuridad confunda al desarrollador y provoque una falla de seguridad en el código durante el desarrollo, en lugar de prevenir un ataque.

La forma en que estás generando aleatoriedad se ve mal, pero no sé lo suficiente sobre la plataforma específica que estás desarrollando para decir si es un enfoque sensato.

Hay otros aspectos sobre los hashes de contraseñas que pueden afectar su seguridad, pero no hay un consenso total en esos puntos.

Hay acuerdo en que es mejor usar hashes nuevos sin debilidades conocidas, en lugar de usar MD5. Sin embargo, ninguna de las debilidades conocidas en MD5 podría usarse para atacar el hash de contraseña en su pregunta. Un ataque contra él seguramente se centraría en las contraseñas débiles, así como en la sal corta.

Luego está la pregunta acerca de si el hash de contraseña debe usar iteraciones o hacer todo tipo de otros cálculos costosos. Tales enfoques desacelerarán el uso legítimo y los ataques de fuerza bruta por el mismo factor. Como tales no son muy efectivos. Aumentar la longitud de una contraseña de 10 a 11 caracteres solo ralentizaría el uso legítimo en un 10%, pero podría ralentizar los ataques de fuerza bruta en un orden de magnitud. Esta es la razón por la que las contraseñas más largas son una mejor manera de ralentizar los ataques.

Eso no quiere decir que los hashes iterados sean inútiles, sí hacen más lentos los ataques. Pero también ralentizan el uso legítimo en su propio servidor, lo que lo convierte en un objetivo más fácil para los ataques DoS.

    
respondido por el kasperd 22.02.2015 - 00:26
fuente
1

Si alguien obtiene acceso a la base de datos con contraseñas, es posible que tengan suficiente acceso en el sistema para leer el código que implementa el hash también. Si lo hacen, entonces conocen la estructura de las contraseñas con hash.

También es común que el atacante sepa al menos una contraseña en el sistema (la suya propia), por lo que si obtienen el hash para su propia contraseña, entonces podrán trabajar en la estructura comparando su propia contraseña y contraseña salada.

La buena noticia es que la salazón funciona incluso si el atacante sabe cómo se construye y almacena la sal. Por muy poco costo al configurar & Al comprobar las contraseñas, hace que sea mucho más costoso / lento descifrar las contraseñas en masa. Por lo tanto, no hay necesidad de preocuparse por ocultar la estructura (por ejemplo, los archivos de contraseñas ocultas de Unix / Linux). En cambio, solo debe preocuparse por generar sales con suficiente entropía para que el trabajo del atacante sea mucho más lento.

Si bien un hash siempre se puede revertir con el tiempo suficiente, el objetivo es hacer que el atacante sea más lento / caro, por lo que a) el atacante se da por vencido y pasa a un objetivo más fácil, b) puedes notar que han sido hackeados y les dicen a los usuarios que cambien sus contraseñas antes de que se hayan comprometido muchas contraseñas.

Si entiendo bien tu PHP, corta algo del hash md5 para reemplazarlo con el salt, reduciendo directamente la seguridad de tu hash. Cambiar la fuerza del hash por un poco de oscuridad es una compensación pobre, ya que la salazón funciona incluso si el atacante sabe cómo se hace. Lo ideal es utilizar una implementación existente como crypt (), ya que su implementación (al menos en los sistemas modernos) debe reflejar las mejores prácticas.

    
respondido por el Colin Phipps 22.02.2015 - 00:54
fuente

Lea otras preguntas en las etiquetas