¿Cuál será el efecto del GDPR en los volcados de contraseñas? [cerrado]

GDPR se relaciona específicamente con información personal identificable, es decir, información que podría usarse razonablemente para identificar a una persona, como dirección, dirección de correo electrónico, nombres de usuario, dirección IP.

Si el volcado de la contraseña contiene solo una contraseña y ningún nombre de usuario, detalles de la cuenta o dirección IP, es probable que no se consideren PII para los fines de GDPR.

Sin embargo, recuerde que si tiene la contraseña de texto sin formato y alguien ha usado algo personal como su contraseña, tal vez firstname_lastname_dob , podría interpretarse como personalmente identificable.

Advertencia: esto no es un consejo legal, no soy abogado, pero tengo mi sede en la UE y trabajo en un equipo para el cumplimiento de GDPR de una empresa que procesa datos confidenciales.

Si bien esta es en realidad una pregunta legal, en cuanto a lo que se refiere a los aspectos prácticos de la seguridad:

• El almacenamiento de cuentas y contraseñas sería información relacionada con una persona identificable, por lo que definitivamente es personal bajo GDPR.

• Solo necesitas almacenar hashes de contraseñas para detectar colisiones. Esto no cambia si los datos son personales bajo GDPR, solo los convierte en datos seudónimos.

• La forma más práctica de almacenar contraseñas que veo para este propósito es una tabla de dos filas con el hash de la contraseña y el número de veces que se ha encontrado. Solo se deben incluir las contraseñas donde ese número es > 1, ya que eso garantizaría que no puedan identificar a nadie de forma única.

Implementación específica:

1. El servidor selecciona aleatoriamente y cambia periódicamente salt1
2. El servidor hash su diccionario de hashes de contraseña incorrecta como badphash1 + salt1- > badphash2
3. salt1 enviado servidor- > cliente
4. El usuario ingresa la contraseña en su cliente (navegador)
5. El cliente hash la contraseña, luego hash hash1 + salt1 = > hash2
6. cliente hash2 enviado > servidor
7. El servidor requiere una nueva contraseña (paso 4) si el hash2 está EN badphash2
8. De lo contrario, el servidor crea el salt2 específico del usuario, lo envía al servidor > cliente
9. La contraseña de hashes del cliente + salt2 = > hash3
10. hash3 enviado cliente- > servidor
11. salt2 + hash3 almacenado en el servidor
12. Al iniciar sesión, hash (contraseña + salt2) se verifica contra hash3.

De esta manera, la sal no es la misma para todas las contraseñas. Esto sigue las mejores prácticas de almacenamiento y transmisión.

IOW: No hay ninguna razón de seguridad para almacenar contraseñas de texto sin formato, ni siquiera para verificar si hay duplicados. Incluso eso se puede hacer en hashes sin comprometer nada.