Corto: No hay muchas mejoras de seguridad para el hash nuevamente. Pero el hash es mejor que el texto simple (no filtra directamente la contraseña).
Aparentemente, el segundo hash está destinado a proteger contra la recuperación de contraseñas en caso de que la base de datos se vea comprometida. En este escenario, la protección es tan buena como lo difícil que es resolver la entrada $ _POST ['hash'] para la operación de hash. Esta entrada no es lo suficientemente impredecible, al menos no cuando se usan claves débiles.
Hay algunas sugerencias que podrías intentar para fortalecer las cosas.
Derivación de clave basada en contraseña
El hash habitual no es una forma recomendada de tratar con contraseñas. Esto se debe a que al menos una fracción de los usuarios siempre tienden a tener contraseñas muy débiles. La contraseña débil siempre es débil, pero hay mejores formas que el hash habitual para trabajar con contraseñas. scrypt paper ilustra la eficacia de diferentes PBKDF (y algunos hashes) contra contraseñas de forzamiento de la fuerza bruta de diferentes niveles de entropía.
Si desea proteger mejor la contraseña + el nombre de usuario, no use sha256, sino una función de derivación de clave basada en contraseña (también conocida como hash lento o hash de contraseña, algunos de ellos en realidad usan sha256 debajo del capó; búsqueda en scrypt, bcrypt, PBKDF2 para más detalles).
La combinación de Contraseña + Nombre de usuario es (a menudo) vulnerable a la adivinación de fuerza bruta, así como a las tablas de arco iris. (En caso de que espere que la conexión SSL no proteja suficientemente las credenciales).
Por cierto, si calcula el hash de contraseña en el lado del cliente, puede ser posible eliminar la necesidad de que el lado del servidor conozca la contraseña. De esta manera, la posibilidad de que el sitio web filtre la contraseña se reduce significativamente.
Si el usuario utiliza la misma contraseña o una contraseña similar en otros sitios, el resultado no se puede utilizar para estos fines.
Usando la misma información de autenticación cada vez
Comprendí que el usuario se autentica con
js > hash = sha256 (Contraseña + Nombre de usuario);
siempre. ¿Derecha? Esto tiene posibilidad de reproducir las credenciales más tarde. (Nota: en muchos casos, SSL impide la reproducción y la reproducción, pero el hecho de que las CA se hayan roto ocasionalmente no siempre es infalible).
Para eliminar esta posibilidad de reproducción, puedes hacer lo siguiente:
Si el servidor conoce la versión derivada de su contraseña (ya sea resultado PBKDF o hash superior [es decir, se almacena en el servidor cuando se autentican por primera vez]), en lugar de volver a enviar el valor, se podría usar protocolo de desafío de respuesta a desafío .
Algunos protocolos de desafío-respuesta más complejos, como el SRP, se basan en el "conocimiento cero" y proporcionan conceptos de seguridad demostrables. Incluso los protocolos de respuesta-desafío bastante simples pueden impedir la necesidad de enviar la contraseña o el valor derivado de la contraseña directamente, pero el cliente simplemente envía algo que convencerá al servidor, pero no permitirá una repetición.
Leer más
Hay una pregunta relacionada en crypto.SE: ¿Es más fácil atacar con el hash de contraseña lento en el lado del cliente que en el lado del servidor? donde Pa Eblo Ebermann sugirió PBKDF basado en el cliente y la mejor respuesta de Thomas Pornin también sugiere que aplicar PAKE (SRP).