GDPR对密码转储有什么影响？

Question

GDPR修改了许多数据保护法，但它将如何影响已转储的密码数据库？

目前，这些可以用来计算出最常见的密码，网站可以利用这些知识来防止人们选择过于常见的密码。

在GDPR下是否仍然允许这样做，因为密码数据库可以被视为个人数据，如果不使用匿名的密码，以便在没有账户细节的情况下存储这些密码就可以解决问题，还是仍然将密码视为个人信息？

Answer 1

GDPR具体涉及个人可识别的信息，即可以合理地用于识别某人的信息，如地址、电子邮件地址、用户名、IP地址。

如果密码转储只包含密码，没有用户名、帐户详细信息或IP地址，则就GDPR而言，它们很可能不被视为PII。

但是，请记住，如果您有纯文本密码，并且有人使用了一些个人的密码，可能是firstname_lastname_dob，这可以被解释为个人身份。

标准警告:这不是法律建议，我不是律师，但我在欧盟工作，并在一家处理敏感数据的公司的GDPR合规团队工作。

Answer 2

虽然这在很大程度上确实是一个法律问题，但究竟是什么关系到安全的实际性：

• 存储accounts+passwords将是与可识别的人有关的信息，因此在探地雷达下绝对是个人信息。
• 您只需要存储密码哈希以捕获冲突。这并不会改变GDPR下的数据是否属于个人数据，而只是将其转化为假名数据。
• 为此目的，我看到的最实用的存储密码的方法是一个两行表，其中包含密码的散列和找到密码的次数。只有这个数字大于1的密码才应该包括在内，因为这将确保他们不能唯一地识别任何人。

具体执行情况：

1. 服务器随机选择并定期更改salt1。
2. 服务器将其错误密码散列字典哈希为badphash2 1+salt1 1->badphash2 2。
3. salt1发送服务器->客户端
4. 用户在他的客户端(浏览器)输入密码。
5. 客户端哈希密码，然后散列hash1+salt1=>hash2
6. hash2发送客户端->服务器
7. 如果hash2在badphash2中，服务器需要新密码(步骤4)
8. 否则，服务器将创建特定于用户的salt2，将其发送给服务器->客户端。
9. 客户端散列password+salt2=>hash3
10. hash3发送客户端->服务器
11. 存储在服务器上的salt2+hash3
12. 在登录时，将检查散列(password+salt2)和hash3。

这样，盐对所有密码都是不一样的。这遵循最佳存储和最佳传输实践。

IOW:没有安全理由来存储纯文本密码，甚至没有检查副本。即使这样，也可以在不损害任何东西的情况下进行散列。