mysql - 通过使用公钥和受用户自己的密码保护的私钥配对来保护 Web 应用程序数据库中的 PII？

Question

目标:

我希望允许用户在自定义网络应用程序(受支持的托管环境中的 PHP/MySQL)中创建问题并从其他用户那里收集信息，并保护收集到的数据。

背景:

所有用户回答的默认问题都足够笼统，不能被解释为个人身份信息 (PII)，因此限制了我保护它的责任，但创建自己问题的用户可能会要求提供 PII，然后成为责任。

我想做的是以这样一种方式保护这些信息，即如果托管帐户或数据库遭到破坏(或两者!)，如果不进行大量工作，PII 将无法恢复，即使那样, 理论上只有一小部分是可回收的。

建议的解决方案:

假设 MySQL 的内置 AES_ENCRYPT()/AES_DECRYPT() 函数用于加密 PII 表，密码短语需要存储在托管账户中，因此如果托管账户被泄露，数据可以很容易地读取。

由于用户的密码受到很好的保护(用盐散列)，我正在考虑在身份验证期间捕获他们的明文密码，对其进行加密，并将其存储在 PHP session 中，直到用户注销。

将为每个用户创建一个公钥/私钥组合，私钥受用户密码 + salt 的密码保护。

然后，当基于该用户的自定义问题的 PII 数据添加到数据库时，用户的公钥将用于加密他们通过应用程序收集的 PII。当读取数据时(仅当用户登录时)，数据将使用用户的私钥(使用他们的密码 + salt 解锁)进行解密。

我看到的好处是:

1. 在最坏的情况下，服务器完全受损，读取应用程序代码以查找加密 key ，解密 PHP session 文件以查找用户密码，然后解密与该用户关联的 PII 表中的条目，然后 仅可以恢复从当前登录用户的问题中收集的 PII。任何未登录的用户都是安全的。
2. 即使是 DBA 或类似人员也无法读取 PII。

我看到的缺点是:

1. 用户密码在登录时以可恢复的形式存储。
2. 忘记密码的用户将无法访问他们的数据。
3. 由于加密，每个相对较小的数据位都会在数据库中占用更多空间。

我的问题:有更好的方法吗？

Answer 1

从安全角度来看，我发现此设计存在一些问题。首先，绝不能加密密码，这是由 CWE-257 确定的漏洞。 .

此外，出于多种原因，MySQL 的 AES_ENCRYPT() 完全是垃圾。它使用 EBC 模式，这里有一个很好的例子来说明为什么这是垃圾:

原始图片:

EBC 模式(这是 mysql 的 AES_ENCRYPT() 使用的模式):

但是如果攻击者破坏的数据库将通过启用 query log 来击败 AES_ENCRYPT() .

应避免使用用户密码进行加密，您应该使用密码随机数。如果确实使用密码，请确保使用 String2Key 函数。您还必须将 CBC 或 CMAC 模式与 random iv 一起使用.我真的看不出非对称密码学有什么帮助。非对称加密非常慢，占用大量内存。当攻击者控制消息时，它保护的数据会变得不那么安全，因为您可以比较密文消息。这就是为什么随机 IV is important ，而在非对称世界中，您没有这种级别的保护。

key 生成应该类似于:$key=string2key($base_nonce.$salt.$user_password)

确保 string2key 函数的输出与键空间的大小相同。所以 aes 128 需要一个 128 位的 key 。每个密码都应该有自己的$salt，$base 是一个存储在文本文件中的加密随机数。 (攻击者在破解 key 之前必须读取此文件，如果这个值很大，如 128 位，那么它是一个有争议的问题。)每条消息都需要它自己的 $iv 并且这个值也必须是一个加密随机数(类似于盐)。我将从 /dev/urandom 生成 $salt、$iv 和 $base_nonce。 IV 可以明文形式与密文一起存储在数据库的列中。

从法律的角度来看，即使您构建了一个安全的密码系统，您仍然会面临内部威胁的问题，如果服务器完全受到威胁，所有数据仍将受到威胁。这真的不是工程问题。

抵御法律威胁的最佳方法是由经验丰富的律师撰写的强有力的条款和条件。