1153 votos

Secure hash y sal para PHP contraseñas

Actualmente se dijo que MD5 es parcialmente inseguro. Teniendo esto en cuenta, me gustaría saber qué mecanismo utilizar para la protección de la contraseña.

Esta pregunta, Es la "doble hashing" de una contraseña menos seguro que sólo hash de una vez? sugiere que el hash varias veces puede ser una buena idea, considerando que Cómo implementar la protección de contraseña para archivos individuales? sugiere el uso de la sal.

Estoy usando PHP. Quiero un rápido y seguro cifrado de la contraseña del sistema. Hash de una contraseña de un millón de veces puede ser más seguro, pero también más lento. Cómo lograr un buen equilibrio entre velocidad y seguridad? También, me gustaría que el resultado tiene un número constante de los personajes.

  1. El mecanismo de hash debe estar disponible en PHP
  2. Debe ser seguro
  3. Se puede utilizar sal (en este caso, son todos los que sales igual de bueno? ¿Hay alguna forma de generar buenos sales?)

También, debo almacenar dos campos en la base de datos (uno con MD5 y otra con SHA, por ejemplo)? Sería más seguro o unsafer?

En el caso de que yo no era lo suficientemente claro, quiero saber que función hash(s) a utilizar y cómo escoger un buen de sal con el fin de tener un seguro y rápido mecanismo de protección por contraseña.

Preguntas relacionadas que no llegan a cubrir mi pregunta:

¿Cuál es la diferencia entre el SHA y MD5 en PHP
Simple Cifrado De La Contraseña
Seguro métodos de almacenamiento de claves, contraseñas de asp.net
¿Cómo implementar salado de contraseñas en Tomcat 5.5

974voto

Robert K Puntos 14893

TL;DR

Qué no hacer

  • No limitar lo que los usuarios pueden introducir los caracteres de las contraseñas. Sólo los idiotas de hacer esto.
  • No se limita la longitud de una contraseña. Si los usuarios desean una frase con supercalifragilisticexpialidocious en ella, no les impidan el uso de ella.
  • Nunca guarde su contraseña de usuario en texto plano.
  • Nunca envíe un correo electrónico una contraseña a su usuario , salvo cuando hayan perdido el suyo, y le envió un temporal.
  • Nunca, jamás de registro de contraseñas de cualquier manera.
  • Nunca hash de las contraseñas con SHA1 o MD5, o incluso SHA256! Moderno galletas puede exceder los 60 y los 180 mil millones de hashes por segundo (respectivamente).

Qué hacer

  • Uso scrypt cuando pueda; bcrypt si usted no puede.
  • Uso PBKDF2 si usted puede utilizar cualquiera de las bcrypt o scrypt, con SHA2 hashes.
  • Restablecer todos contraseñas de la base de datos se ve comprometida.
  • Implementar un razonable 8-10 de caracteres de longitud como mínimo, además de requerir al menos 1 letra mayúscula, 1 letra minúscula, un número y un símbolo. Esto mejorará la entropía de la contraseña, en vez de hacer que sea más difícil de roer. (Vea "¿Qué hace que una buena contraseña?" en la sección de debate.)

¿Por qué los hash de las contraseñas de todos modos?

El objetivo detrás de hash de las contraseñas es simple: la prevención de la malicioso acceso a las cuentas de usuario por comprometer la base de datos. Por tanto, el objetivo de hashing de la contraseña es para disuadir a un hacker o cracker por lo que les costó demasiado tiempo o dinero para calcular las contraseñas de texto sin formato. Y el tiempo/costo son los mejores elementos de disuasión en su arsenal.

Otra razón por la que te quiero un buen, sólido hash de las cuentas de usuario es darle suficiente tiempo para cambiar todas las contraseñas en el sistema. Si su base de datos se ve comprometida usted tendrá tiempo suficiente para al menos bloquear el sistema, si no cambiar todas las contraseñas en la base de datos.

Jeremiah Grossman, CTO de Whitehat Security, declaró en su blog después de una reciente recuperación de la contraseña que se requiere de fuerza bruta ruptura de su protección con contraseña:

Curiosamente, en vivir esta pesadilla, he aprendido MUCHO, no sabía de descifrado de contraseñas, el almacenamiento y la complejidad. He llegado a apreciar por qué el almacenamiento de contraseñas es siempre mucho más importante que la complejidad de la contraseña. Si usted no sabe cómo su contraseña es almacenada, entonces todo lo que usted realmente puede depender es la complejidad. Esto podría ser de conocimiento común para la contraseña y el cripto pros, pero para la media de InfoSec o Web experto en Seguridad, lo dudo.

(El énfasis es mío.)

¿Qué hace que una buena contraseña?

La entropía. (No es que estoy totalmente de suscribirse a Randall punto de vista.)

En resumen, la entropía es la cantidad de variación que es dentro de la contraseña. Cuando una contraseña es sólo minúsculas letras romanas, que sólo 26 caracteres. Que no hay mucha variación. Alfa-numérico de las contraseñas son mejores, con 36 caracteres. Pero permitiendo que las mayúsculas y minúsculas, con símbolos, es de aproximadamente 96 caracteres. Eso es mucho mejor que sólo letras. Uno de los problemas es, para hacer nuestras contraseñas memorable que insertar los patrones-que reduce la entropía. ¡Uy!

Contraseña de la entropía es aproximar fácilmente. El uso de la gama completa de caracteres ascii (aproximadamente 96 tipificables caracteres) los rendimientos de una entropía de 6.6 por carácter, que a las 8 caracteres para la contraseña es demasiado baja (52.679 bits de entropía) para su futura seguridad. Pero la buena noticia es: las contraseñas más largas, y las contraseñas con caracteres unicode, realmente aumentar la entropía de una contraseña y hacer que sea más difícil de roer.

Hay una discusión más larga de la contraseña de la entropía en el Crypto StackExchange sitio. Una buena búsqueda en Google también a su vez una gran cantidad de resultados.

En los comentarios que he hablado con @popnoodles, quien señaló que el cumplimiento de una política de contraseñas de X longitud con X cantidad de letras, números, símbolos, etc, en realidad puede reducir la entropía, haciendo que el esquema de contraseñas más predecible. Estoy de acuerdo. Randomess, como verdaderamente al azar como sea posible, siempre es la más segura pero menos memorable solución.

Tan lejos como he sido capaz de decir, de hacer el mundo mejor contraseña es un Catch-22. Su no memorable, demasiado previsible, demasiado corto, demasiado muchos caracteres unicode (difícil escribir sobre un Windows/dispositivo Móvil), demasiado largo, etc. La contraseña No es realmente lo suficientemente bueno para nuestros propósitos, por lo que debemos proteger como si ellos estaban en Fort Knox.

Mejores prácticas

Bcrypt y scrypt son las mejores prácticas actuales. Scrypt será mejor que bcrypt en el tiempo, pero que no ha visto la adopción de un estándar de Linux/Unix o por los servidores web, y no ha tenido una revisión en profundidad de su algoritmo publicado todavía. Pero aún así, el futuro del algoritmo se ve prometedor. Si usted está trabajando con Ruby hay un scrypt de la gema que le ayude a salir, y Node.js ahora tiene su propio scrypt paquete.

Yo sugiero la lectura de la documentación para la cripta de la función , si se quiere entender cómo utilizar bcrypt, o la búsqueda de sí mismo un buen contenedor o usar algo como PHPASS para una mayor legado de la aplicación. Yo recomiendo un mínimo de 12 rondas de bcrypt, si no de 15 a 18.

He cambiado de opinión sobre el uso de bcrypt cuando me enteré de que bcrypt sólo usa blowfish del horario de la llave, con un costo variable mecanismo. Esta última permite aumentar el costo por fuerza bruta una contraseña mediante el aumento de blowfish ya es caro horario de la llave.

Promedio de prácticas

Casi me puedo imaginar esta situación ya. PHPASS soporta PHP 3.0.18 a través de 5.3, por lo que es utilizable en casi todos los imaginables de instalación y debe ser utilizado si usted no sabe de cierto que el entorno admite bcrypt.

Pero supongamos que usted no puede utilizar bcrypt o PHPASS a todos. Entonces, ¿qué?

Probar una aplicación de PDKBF2 con el número máximo de rondas que su entorno/aplicación/usuario-la percepción puede tolerar. El número más bajo que yo recomiendo es de 2500 rondas. También, asegúrese de utilizar hash_hmac() si es que está disponible para hacer la operación más difícil de reproducir.

Prácticas Futuras

Viene en PHP 5.5 es una completa protección de la contraseña de la biblioteca que resúmenes de distancia los dolores de trabajar con bcrypt. Mientras que la mayoría de nosotros se queda con PHP 5.2 y 5.3, en la mayoría de los ambientes comunes, especialmente compartida de los ejércitos, @ircmaxell ha construido una capa de compatibilidad para los próximos API que es compatible con versiones anteriores a PHP 5.3.7.

Criptografía De Recapitulación Y Exención De Responsabilidad

El poder de la computación necesarios para el crack de un hash de contraseña no existe. La única manera para que los equipos "crack" de la contraseña para volver a crear y simular el algoritmo de hash utilizado para asegurarlo. La velocidad de la hash está linealmente relacionada con la capacidad de ataque de fuerza bruta. Peor aún, la mayoría de los algoritmos de hash puede ser fácilmente paralelizado para llevar a cabo incluso más rápido. Esta es la razón por la costosos esquemas como bcrypt y scrypt son tan importantes.

Usted no puede prever todas las amenazas o vías de ataque, y entonces usted debe hacer su mejor esfuerzo para proteger a sus usuarios frente. Si no, entonces usted podría incluso perder el hecho de que fueron atacados hasta que es demasiado tarde... y eres responsable. Para evitar esa situación, la ley de paranoico, para empezar. Ataque de su propio software (internamente) y el intento de robar las credenciales de usuario, o modificar cuentas de otros usuarios o acceder a sus datos. Si no prueba la seguridad de su sistema, entonces usted no puede culpar a nadie sino a ti mismo.

Por último: yo no soy un criptógrafo. Lo que yo he dicho es mi opinión, pero creo que se basa en el buen ol' sentido común ... y un montón de lectura. Recuerden, ser tan paranoico como sea posible, hacer las cosas lo más duro para entrometerse como sea posible, y entonces, si usted todavía está preocupada, póngase en contacto con un white hat hacker o criptógrafo para ver qué dicen de tu código o sistema.

137voto

RichVel Puntos 788

Una mucho más corta y más segura respuesta - no escribir su propio mecanismo de contraseña en todos, utilice uno que está probado y comprobado, y se incorporan en WordPress, Drupal, etc, es decir. Openwall del phpass.

La mayoría de los programadores no tienen los conocimientos para escribir crypto código relacionadas con la seguridad sin la introducción de vulnerabilidades.

Auto prueba rápida: ¿cuál es la contraseña de estiramiento y cuántas iteraciones se debe utilizar? Si usted no sabe la respuesta, usted debe utilizar phpass, como la contraseña de estiramiento es ahora una característica fundamental de la contraseña mecanismos debido a la mucho más rápido Cpu y el uso de la Gpu y los FPGAs para romper contraseñas en las tasas de miles de millones de conjeturas por segundo (con Gpu).

Por ejemplo, usted puede ahora todos los crack de 8 caracteres las contraseñas de Windows en 6 horas con 5 productos básicos de PCs de escritorio con 5 tarjetas gráficas por COMPUTADORA. Esta es la fuerza bruta, es decir. enumerar y comprobación de cada 8 caracteres de la contraseña de Windows, incluyendo caracteres especiales, y no es un ataque de diccionario. También hay muchos arco iris de la tabla de los ataques que se ejecutan en la Cpu y son muy rápidos. Todo esto es debido a que Windows todavía no la sal o el estiramiento de sus contraseñas - no cometa el mismo error que hizo Microsoft!

Ver este excelente respuesta para obtener más acerca de por qué phpass es el mejor camino a seguir.

43voto

Tom Haigh Puntos 32314

Yo no almacenar la contraseña con algoritmo hash de dos maneras diferentes, porque entonces el sistema es, al menos, tan débil como el más débil de los algoritmos de hash en uso.

33voto

Gaurav Kumar Puntos 139

A pesar de que la pregunta haya sido respondida, sólo quiero reiterar que las sales se utiliza para la mezcla debe ser aleatorio y no como la dirección de correo electrónico, como se sugiere en primera respuesta.

Una explicación más detallada está disponible en- http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/

Recientemente tuve una discusión sobre si los hash de las contraseñas con sal al azar los bits son más seguras que las de uno con sal adivinar o conocido las sales. Vamos a ver: Si el sistema de almacenamiento de la contraseña se ve comprometida, como así como el sistema que almacena el azar de la sal, el atacante se tener acceso a hash así como la sal, por lo que si la sal es al azar o no, no importa. El atacante puede generar pre-calculadas las tablas rainbow para descifrar el hash. Aquí viene la parte interesante- no es tan trivial para generar pre-calculadas tablas. Tomemos ejemplo de seguridad WPA modelo. Su contraseña WPA es, en realidad nunca se envían a Punto De Acceso Inalámbrico. En su lugar, se fragmenta con su SSID (el nombre de la red - como Linksys, Dlink, etc.). Una muy buena explicación de cómo esto funciona es aquí. Para recuperar la contraseña de hash, se necesitas saber la contraseña de la sal (nombre de la red). La iglesia de El Wifi ya ha pre-calculadas de las tablas hash que ha top 1000 Ssid y alrededor de 1 millón de contraseñas. El tamaño es de todas las tablas es de alrededor de 40 GB. Como se puede leer en su sitio, alguien utilizó 15 FGPA matrices de 3 días para generar estas tablas. Suponiendo que la víctima está utilizando el SSID como "a387csf3" y la contraseña "123456", va a ser agrietado por los las tablas? ¡No! .. no se puede hacer. Incluso si la contraseña es débil, las tablas no tiene los valores hash de SSID a387csf3. Esta es la belleza de tener al azar de sal. Disuadirá a los crackers que prosperan a los pre-calculadas tablas. Puede detener un determinado hacker? Probablemente no. Pero el uso de al azar sales proporciona una capa adicional de defensa. Mientras estamos en en este tema, vamos a discutir ventaja adicional de almacenamiento de azar sales en un sistema separado. Escenario #1 : los hash de las Contraseñas se almacenan en el sistema X y los valores de sal utilizada para la mezcla se almacenan en el sistema de Y. Estos valores de sal son fáciles de averiguar o conocido (p. ej. nombre de usuario) Escenario#2 : Los hash de las contraseñas se almacenan en el sistema X y los valores utilizados para la sal hash se almacenan en el sistema de Y. Estos valores de sal son al azar. En caso de que el sistema X ha sido comprometida, como se puede adivinar, hay una enorme la ventaja de usar al azar de sal en un sistema separado (Escenario #2) . El atacante tendrá que adivinar, además de los valores a ser capaz de crack hash. Si un programa de 32 bits se usa sal, 2^32= 4,294,967,296 (unos 4,2 millones de euros) iteraciones puede ser requerido para cada adivinado la contraseña.

27voto

JonoCoetzee Puntos 339

Sólo quiero señalar que PHP 5.5 incluye un hash de la contraseña de la API que proporciona un envoltorio alrededor crypt(). Esta API simplifica considerablemente la tarea de la mezcla, comprobar y repetir constantemente los hash de las contraseñas. El autor también ha lanzado un paquete de compatibilidad (en la forma de un solo password.php el archivo que usted, simplemente, require de uso), para aquellos que utilizan PHP 5.3.7 y posterior y desea hacer uso de este derecho ahora.

Sólo es compatible con BCRYPT por ahora, pero se persigue el objetivo de ser fácilmente ampliado para incluir otros contraseña técnicas de hashing y debido a que la técnica y el costo se almacena como parte del hash, los cambios de su fuente preferida de hash técnica/costo no invalidará actual hash, el marco de trabajo automáticamente, utilice la técnica correcta de costo a la hora de validar. También se ocupa de la generación de un "seguro" sal si no se define explícitamente su propio.

La API expone cuatro funciones:

  • password_get_info() - devuelve información sobre el dado de hash
  • password_hash() - crea un hash de contraseña
  • password_needs_rehash() - comprueba si el hash coincida con las opciones dadas. Útil para comprobar si el hash se ajusta a la técnica actual/costo esquema que permite repetir si es necesario
  • password_verify() - verifica si la contraseña coincide con un hash

En el momento en que estas funciones aceptar la PASSWORD_BCRYPT y PASSWORD_DEFAULT contraseña constantes, que son sinónimos en el momento, con la diferencia de que PASSWORD_DEFAULT "puede cambiar en las nuevas versiones de PHP cuando más nuevos, más fuertes algoritmos de hash son compatibles." El uso de PASSWORD_DEFAULT y password_needs_rehash() en el inicio de sesión (y repetir constantemente si es necesario) debe asegurarse de que su hashes son razonablemente resistentes a los ataques de fuerza bruta con poco o ningún trabajo para usted.

EDIT: me di cuenta de que esto es mencionado brevemente en Robert K la respuesta. Voy a dejar esta respuesta aquí, ya que creo que es un poco más de información sobre cómo funciona y la facilidad de uso que ofrece para aquellos que no saben de seguridad.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X