¿Por qué tengo hash de las contraseñas de usuario con PDKDF2 cuando los datos del usuario se almacenan en la misma base de datos?

Es posible que un atacante no tenga que obtener acceso a su base de datos para obtener las contraseñas de sus usuarios.

Por diseño, los datos almacenados en una base de datos están separados por tablas. La información como nombres de usuario y contraseñas debe estar en una tabla diferente de los detalles del usuario como nombre y tal. Este es un diseño de esquema de base de datos básico.

Si un atacante compromete su aplicación utilizando técnicas como las inyecciones de SQL, es posible que solo puedan acceder a la tabla que contiene las contraseñas.

Incluso suponiendo que el atacante logre obtener acceso a toda su base de datos, hay otros factores a considerar. La información del usuario no es lo único importante en su aplicación. Si el atacante cambia la información en la base de datos directamente, lo más probable es que sus acciones se registren. Esto hace que sea relativamente fácil encontrar y corregir cualquier modificación no deseada.

Sin embargo, si el atacante inicia sesión en una cuenta de usuario a través de la página de inicio de sesión de su aplicación, sería difícil diferenciar lo que se pretende y el acceso no deseado. Podría causar mucho daño potencial.

Además, muchos usuarios utilizan las mismas combinaciones de nombre de usuario y contraseña en varios sitios. Si un atacante compromete la información de la cuenta en su sitio, podría acceder a todas las demás cuentas en línea del usuario. Esto es malo.

Siempre hash tus contraseñas.

La gente tiende a reutilizar contraseñas para diferentes sitios. ¡No pueden recordar 20 contraseñas seguras diferentes para 20 sitios diferentes! El uso de un hash de contraseña seguro es una forma responsable de limitar el daño en el caso desafortunado de un compromiso del sitio. Sus datos en su sitio estarán expuestos, pero no sufrirán el compromiso de cuentas de alto valor (tanto para ellos mismos como para los atacantes) como Facebook (spam), Gmail (compromiso de identidad en línea completo) o Amazon (permite compras). a través de los datos de la tarjeta de crédito guardados automáticamente por el usuario, sin necesidad de CVV).

(No, los nombres completos y los nombres de usuario no deben estar en tablas separadas como una cuestión de "diseño básico de esquema de base de datos". Cada usuario tiene un nombre y un nombre de usuario, por lo que deben estar en la misma tabla. OTOH, más complejo Es probable que los datos, como la libreta de direcciones de las direcciones de correo electrónico de un amigo, se dividan entre varias tablas, por lo que estoy de acuerdo con que PDKDF2 podría ayudar a limitar el daño de una única inyección de SQL).

Si sus contraseñas no están cifradas, sino almacenadas "como están", entonces un atacante que obtiene un acceso de solo lectura a la base de datos aprende todas las contraseñas, lo que le permite iniciar sesión como cualquier usuario y haga lo que estos usuarios puedan hacer, lo que incluye, como usted dice, editar su información personal. Esto significa que el atacante puede escalar el acceso de solo lectura a un acceso de lectura-escritura.

El acceso de solo lectura no es un escenario improbable. Esto es lo que obtiene el atacante cuando roba una vieja cinta de respaldo.

Consulte esta publicación del blog para obtener más detalles.