Bcrypt (4) (= 4 iteraciones) versus SHA512 o algo diferente con sal única por contraseña?

Question

Antecedentes:

Quiero añadir una entrada a mi pequeño sitio, que es una aplicación PHP en línea, lo que me gustaría construir a ser capaz de soportar tanto la actividad del usuario en el futuro.

Antes de continuar con la implementación de LightOpenID, deseo agregar un inicio de sesión normal. El libro del que estaba aprendiendo se llama Head First PHP & MySQL (2008) y el código final del capítulo usa SHA('$user_password') como parte de la consulta mysql.

Cuando tomo interés en la escritura de Jeff Atwood, soy muy consciente de brypt como de scrypt. Pero visto que no hay una implementación php de scrypt y no tiene un servidor dedicado para ejecutarlo, decidí al menos investigar la implementación de bcrypt por el momento.

Sin embargo, no soy completamente ingenuo, sé que debo vigilar para no exceder mis recursos de alojamiento muy humildes. La aplicación php en sí siempre debe ser lo primero antes que cualquier otra cosa con respecto a los recursos.

Andrew Moore's method parece agradable (aunque voy a tener que ver cómo ponerlo en práctica en PHP 5.2.17 que utiliza mi anfitrión) y viene con una punta de velocidad del hardware:

Usted debe seleccionar un número de de rondas que resulta en 200-250 ms de trabajo . Parte de la razón por la cual bcrypt es seguro es que es lenta. Usted debe asegurarse de tener un número de rondas que mantiene esa característica. - Andrew Moore

Otro usuario afirma que para él correr microtime() da 0,314 para Bcrypt (9), que de este modo sería casi óptimo.

La pregunta:

visto ya que sólo tengo recursos muy humilde a mi disposición y me gustaría hacer el mejor de ellos, dejando la mayor parte de la propia aplicación php, ¿Todavía estoy mejor usando Bcrypt (4) en lugar de otra cosa?

Bcrypt (4) devuelve verdadero casi al instante, pero aún así mantener esa característica Moore habla? (¿Sería la RAM parte relativa que hace que sea más difícil para fuerza bruta GPU?) ¿O SHA512 o algo más en realidad ser tan rápido pero más seguro en este punto?

Espero que Bcrypt (4) gane en esta situación, pero demonios, ¿lo sé, verdad? : p

Answer 1

La seguridad siempre se trata de lo que está tratando de proteger.

Si le preocupan más sus recursos que su seguridad, bcrypt (2) ya es excesivo. Ningún hacker tratará de romperlo para una aplicación normal, teniendo sitios más fáciles como LinkedIn y muchos otros, que solo usan funciones de la familia sha, con una única iteración, y sin sal. Van a buscar la 'fruta que cuelga bajo'. O podrían seguir intentando piratear su aplicación, pero no en la parte de encriptación de contraseña.

SHA-512 no es mucho más seguro que SHA-1 como algoritmo de hashing de contraseña [1], no ha sido diseñado para ese propósito.Sin embargo, todavía se pueden usar como primitivas para crear algoritmos criptográficos seguros, pero eso es algo que ninguna persona debería hacer. Para que se considere seguro, los algoritmos criptográficos deben ser públicos para ser revisados ​​por pares, y deben pasar la prueba del tiempo. Y obviamente, debe estar diseñado para lo que vas a usar. MD5, SHA-X, etc. son algoritmos criptográficos, pero no fueron diseñados para almacenar contraseñas.

Simplemente agregue o elimine rondas a su bcripta. En este caso, usaría 1 o 2. También tenga en cuenta que 1 ronda! = 1 iteración. Se incrementan exponencialmente. Si lees sobre cómo funciona bcrypt, verás que hay mucho más que iteraciones. Por ejemplo, mencionó 'sal única por contraseña'. Bcrypt ya tiene eso.

[1] Para otras cosas Obviamente es más seguro

Answer 2

Usted debe mirar la seguridad del sistema, no sólo de bcrypt.

Ciertamente, si desea almacenar contraseñas, bcrypt o PBKDF2 es la forma de proceder. Asegúrese de usar una sal aleatoria lo suficientemente grande por usuario o contraseña. Luego intente maximizar el número de iteraciones. Si eso es pequeño, entonces es pequeño, pero cualquier iteración más es mejor que nada.

Tenga en cuenta que esto hace poco contra el espionaje o el hombre en los intentos intermedios (MitM). Deberías usar SSL para eso; la contraseña o el hash (si lo hace el lado del cliente hash) se pueden reproducir de lo contrario.

Además, si quiere protegerse contra los ataques de fuerza bruta (los atacantes que intentan las contraseñas más comunes) debe crear (o copiar) un buen esquema de administración de contraseñas. Limite la cantidad de inicios de sesión incorrectos y trate de que los usuarios creen contraseñas seguras. También limite la cantidad de información que le devuelve a su usuario con respecto a los inicios de sesión incorrectos, ese usuario puede ser el atacante.

Answer 3

¿O SHA512 u otra cosa realmente sería tan rápido pero más seguro en este punto?

lentitud es una característica importante de los algoritmos hash de la clave (de los cuales, bcrypt es uno, pero SHA-512 por sí mismo no es) - el más lento su algoritmo es (en relación con otros algoritmos), más difícil es para un atacante a las contraseñas de fuerza bruta basadas en los hashes. Desde esta perspectiva, una sola ronda de SHA-512 es menos adecuada que bcrypt para almacenar contraseñas de forma segura, porque es considerablemente más rápida.

En mi opinión, el mejor enfoque es elegir un algoritmo hash de contraseña (bcrypt, PBKDF2, scrypt) y luego ajustar el factor de trabajo para ofrecer la mejor compensación entre velocidad y seguridad, dados los recursos informáticos disponibles para usted y las características de su sistema. Un factor de trabajo más alto = más seguro, pero también más intensivo en recursos.

La buena noticia es que los usuarios suelen utilizar su función de inicio de sesión con poca frecuencia en comparación con otras funciones, por lo que el impacto de una función de inicio de sesión más lenta/de recursos generalmente no es un gran problema.