¿Qué tan peligroso es almacenar la contraseña con hash en el almacenamiento local?

Es realmente peligroso.

El uso del almacenamiento local para almacenar identificadores de sesión nunca se recomienda ya que los datos siempre son accesibles por JavaScript .

Por favor, utilice cookies para mitigar este riesgo utilizando el indicador httpOnly .

Un solo ataque XSS (Cross Site Scripting) podrá robar todos los datos en estos objetos y / o cargar información maliciosa, por lo que no considere que el "almacenamiento local" sea confiable y menos para un identificador de sesión / contraseña hash.

Ref: enlace

Hay varios problemas con esto.

Primero, el valor SHA-256 con sal es un equivalente de contraseña; cualquier atacante que tenga acceso a ese valor puede simplemente pasarlo directamente al servidor para autenticarse. No hay necesidad de fuerza bruta del hash.

Segundo, usar almacenamiento local en lugar de una cookie marcada con httpOnly significa que este valor equivalente de contraseña es potencialmente vulnerable a ser robado por ataques XSS. Cualquier script que se ejecute en su sitio tiene acceso completo a estos datos.

Y en tercer lugar, una sola ronda de SHA-256 es una mala elección para el hashing de contraseñas, ya que se puede forzar con fuerza bruta con relativa facilidad. Es completamente posible que cualquier atacante que logre obtener el hash la obligue a obtener la contraseña del usuario y luego la use para atacar las cuentas del usuario en otros sitios (suponiendo que el usuario reutilice las contraseñas entre sitios, lo que desafortunadamente es bastante común).

Peligroso. No recomendado.

Algunas razones por las que;

1. Ataques MITM. En el caso de un ataque de canal lateral, una degradación del código, un relleno o debilidades en el algoritmo de cifrado que envía una contraseña con hash a través de la línea puede ser forzada de manera bruta una vez que se adquiere.

2. Complementos de navegador nefarios / vulnerables. Hay miles de complementos personalizados que se ejecutan en los navegadores de sus clientes. Algunos de estos están diseñados para hacer cosas malas, mientras que otros históricamente han demostrado ser inseguros, lo que lleva a robar información adicional desde el navegador.

3. Rebinding DOM & Ataques XSS. Las debilidades en el código del cliente pueden ayudar a los atacantes a robar las credenciales almacenadas en el navegador.

4. Vulnerabilidades en el navegador. Aquí un navegador vulnerable también puede conducir al robo de credenciales. Normalmente es útil para los tipos de ataques de reproducción de sesión.

Algunas formas de proteger a sus clientes;

1. NO ALMACENAR INFORMACIÓN SENSIBLE EN EL NAVEGADOR DE CLIENTES.

2. Envuelva su entrega de código en una conexión TLS con cifrados fuertes y nada más antiguo que v1.2. Esto requiere claves fuertes, ECC / RSA superiores a 2048 bits, nada menos que un algoritmo SHA512 para los certificados x509.

3. Configure su aplicación para hacer cumplir una seguridad sólida usando las opciones content-security-header .

4. Asegúrese de que su aplicación no filtre datos confidenciales o, si se está desarrollando, use un identificador para asegurarse de que nada sensible abandone el servidor.

5. Mantenga su servidor actualizado y las aplicaciones actualizadas, incluido el firmware.

Este enfoque es estrictamente menos seguro que almacenar un token / cookie de sesión estándar y enviar la contraseña en texto sin formato.

En primer lugar, la contraseña de hash del cliente funciona como un reemplazo de contraseña, por lo que el efecto de seguridad en el lado del servidor es irrelevante. En caso de una violación de datos del servidor, lo único que evitará este hashing del lado del cliente es que el atacante vea su contraseña original, que ya debería ser aleatoria y única mediante el uso de un administrador de contraseñas. Un atacante aún podrá autenticarse al enviar directamente la contraseña con hash al servidor.

Si este fuera el único problema, sería tan seguro como una autenticación estándar + contraseña única aleatoria, pero como la contraseña con hash se almacena en la memoria local, también aumenta la posibilidad de que la contraseña se filtre. Cualquier ataque simple que acceda al almacenamiento local entregará su contraseña de hash, que ahora se puede usar para iniciar sesión (vea mi primer punto).

Tercero, una sola ronda de SHA256 no es segura en absoluto. Cualquier atacante determinado romperá una contraseña de longitud media en muy poco tiempo, y no hay seguridad en la oscuridad, ya que cualquier persona que tenga acceso al sitio web podrá ver el código javascript, lo que significa que un atacante no tendrá que encontrar el algoritmo. se utilizó y cuántas rondas se realizaron.

Para obtener más información sobre por qué el hashing del lado del cliente es una idea mala / superflua, vea esto: Hash de contraseña del lado del cliente

Al final, lo más preocupante es que esos desarrolladores siguen un enfoque no estándar, y esto me haría pensar dos veces antes de usar su sitio web.