Ya sé que voy a cifrar la contraseña del usuario n veces en sha512 o n * x en sha1 antes de enviarla al servidor. Una vez en el servidor, usaré bcrypt set para usar ~ La centésima de segundo. Antes de continuar, en mi razonamiento detrás de usar sha512 en lugar de sha1, me gustaría mencionar algunas cosas. Primero, sé que la seguridad del lado del cliente es una broma. Segundo, sé que un ataque Man-in-the-middle podría eliminar el javascript de la página de la función hash. Por último, me doy cuenta de que esto significará que las personas no podrán iniciar sesión sin habilitar el javascript.
Actualmente estoy usando sha512 set para usar ~ 1s en ie8 [2], está configurado como tal.
- Toma la contraseña y el nombre de usuario del usuario.
- Agrega una fuente estática (para alargarla realmente y nada más).
- Hash a través de la función de hashing, en este caso sha512.
- Toma ese hash, hazlo a través de sha512 con el número de bucle actual empaquetado en un solo byte.
- repite el paso 4 n veces.
- Una vez que haya terminado, tome ese valor y colóquelo en el campo de contraseña.
- finalmente, permita que el sistema POST al servidor.
Ahora bien, ¿cuál es la ventaja de hacer n * x hashes de sha1 frente a las n veces de sha512? El punto detrás del uso de este sistema es que, en el caso de que se produzca una fuga en la base de datos, el atacante tendrá que aumentar la cantidad de tiempo dedicado a tratar de encontrar la contraseña por tiempo. Además, al incluir el hash antes de que llegue al servidor (junto con el uso de TLS), lo hace, de modo que, en el caso de algún error extraño, la contraseña nunca se ve como texto simple.
Creo que sha512 es una mejor opción ya que sha1 ya está roto y, por lo tanto, su seguridad no vale la pena, sino por el otro lado. La biblioteca javascript más rápida que he encontrado para sha512 [1] [] es ~ 50 veces más lenta que el código nativo, pero la biblioteca sha1 más rápida que he encontrado es solo ~ 17 veces más lenta que el código nativo.
Por lo tanto, se trata de si el sha1 roto va a causar una mayor pérdida en la seguridad general y, por lo tanto, la desaceleración de un atacante que hacer menos iteraciones de sha512, que a partir de ahora no se ha roto ninguna de las familias de sha2. ¿Alguien más ha tratado este tema antes?
[1]: el hecho de fuzzing da como resultado el mismo hash que la implementación de c / php, da como resultado el mismo hash para ~ 300 entradas.
[2]: un año después de que se elimine ie10, me gustaría dejar el soporte para ie8 para poder aumentar el número de hashes a algo más razonable.