如果您在服务器端进行加密和解密，管理员总是有机会在用户不知情的情况下解密数据，方法是修改系统，以便当用户合法解密他或她的数据时，解密密钥被存储以供其他相关方闲暇时使用，例如，在为认股权证服务时。

也就是说，您描述的方案通常与这样的系统实际上是如何构建的，并且在正常使用中是相当安全的。但是，有一些警告或说明。

1. 您不会直接将密码用作密钥。您将使用 PBKDF（例如 bcrypt、scrypt 或 PBKDF2）将密码转换为强随机密钥，并使用对您的应用程序有意义的工作因子。

2. 您通常不会使用此密钥直接加密数据。您将在服务器上生成一个强随机密钥，这将是实际的数据加密密钥 (DEK)。然后，从密码派生的密钥将用作密钥加密密钥 (KEK) 来加密 DEK。这样，如果用户决定更改他们的密码，您将生成一个新的 KEK，您只需重新加密 DEK，而不是所有数据。

3. 使用此系统，您实际上根本不需要存储密码哈希。当用户登录时，您只需要导出 KEK，解密 DEK，并确定它是否可以正确地为用户解密数据。如果可以，则密码正确。如果不是，则不是，您可能无法通过身份验证尝试。取决于应用，这可能是理想的，也可能不是理想的。

这有（至少）两个大缺陷：

• 用户无法轻易更改密码
• 如果数据泄漏，它受到可能是弱密码的保护

更好的是使用随机生成的全强度加密密钥，并使用用户密码对其进行加密。用户可以轻松更改密码（您只需解密/重新加密一件事），如果加密数据落入攻击者手中，它会受到 128 或 256 位熵的保护。

您应该仔细关注客户端登录/身份验证/个人数据系统，但您最初的帖子仅根据加密技术考虑用户的私有加密数据，而不是根据其随后的访问和存储方式。我要特别强调对可能在路径中存在单点故障的方法的依赖，或者一般希望您的软件/系统将“设置得足够好”。从长远来看，这不是一个非常安全的假设，尽管它通常是“默认”的。改为假设：

• 几乎所有广泛使用的软件都会定期发现新的漏洞。您选择的软件/数据库/操作系统/面向网络的服务也是如此。
• 许多企业将成为目标。你的也是。

因此，“分层”安全在这里与任何地方一样重要。这意味着不要让加密成为能够让您的用户数据安全的“瓶颈”。不要只相信一层系统（加密或任何其他类型）来保证它的安全。考虑到在某些时候您的数据库和加密/解密路径或证书将同时变得易受攻击，如果没有“进一步的障碍”阻碍，攻击者或内部人员可以读取存储的私人用户数据，并直接面对这种威胁。

因此，除了其他所有内容之外，这里还有更多关于设计安全措施的想法。为了方便起见，我已经从身份验证/登录的角度对其进行了描述，但同样的原则适用于来自客户端的所有存储数据（如果它是敏感的）：

将每个用户帐户的加密登录数据拆分为两个或多个并将它们分开。例如，将加密的密码或用户数据放在一个 SQL DB 服务器上 - 但确保需要个​​性化的随机盐在第二个独立的 SQL DB 服务器上对其进行解密。或者，一旦加密，将个性化的每个帐户解密密钥分成两半存储在两个单独的数据库服务器上。

基本上，它迫使一个人闯入并潜入两台服务器，而不是一台。他们还必须留下两条审计线索，而不是一条。

确保获得访问权限的人不会轻易发现这使他们可以访问另一个（不同的数据库引擎/操作系统风格以减轻 RDBMS/操作系统漏洞，如果可行的话，可能会使用不同的登录凭据或站点，以实现单个人更难在不标记警报的情况下获得物理/逻辑访问）......

未来的“获得访问权限的人”可以很容易地成为内部人员和外部人员，或者使用您网络上的其他可访问设备或您和您的员工拥有的设备（例如在家工作的员工）进行枢转，因此让内部人员难以复制/skim/replicate DB，而不是以受控的脚本方式。

然后查看这些数据库服务器的访问控制。可能面向公众且可能与大多数员工在同一局域网上的 Web 服务服务器风险较高，但身份验证/客户端 RDBMS 服务器只需要很少的员工维护访问，并且专门用于存储客户端数据，使得与日志中较低的“背景聊天”相比，任何滥用/异常都更加突出。因此，也许保存敏感数据的服务器可以通过观察异常访问模式来保护，这些服务器位于由信誉良好的企业（如果是内部人员，则不是你的）运行的更好的强化或专家托管的单独网络上，也许它们可能只会在很短的时间内做出响应对外的有限方式，例如限制他们响应的 IP，

然后以同样的方式查看路径的其余部分。攻击者可以坐在更广泛的系统中的什么位置，让他们以有意义的方式获取数据或增强他们的访问权限（或者可能访问一旦与他们获得的其他数据相结合就变得有意义的数据）。谁实际上必须能够坐在那里，并且可以合理限制固有的伤害范围？

例如，很少有人需要访问登录/身份验证服务器或私钥/证书。也可能只有少数人/设备需要物理和逻辑访问。

（如果您不能完全进行“端到端”加密，也许您仍然可以在一定程度上“黑匣子”这方面的事情。例如，执行实际加密/解密的服务器可能只能通过这种方式访问，持有加密密钥/静态数据的数据库服务器只能通过这种方式访问，并且每个服务器都只有非常有限且定义明确的访问需求以进行维护，并且仅与特定的安全非互联网 IP 通信和（用于用户数据处理）通过非常有限的数据 API。您的 Web 服务将这些视为黑匣子，接收回加密数据（从其角度来看端到端加密），除了这些极少数点之外，您的其他系统或用户只能看到加密的用户数据。 )

不要忘记关注日常风险（备份、电源/硬件/连接问题、关键人员突然流失）。

将这些放在一起，事情就会变得“如此灾难性的错误”而导致严重的业务损失变得更加困难。

我希望传达的是，不要仅仅将加密视为您的“解决所有问题”。查看允许内部人员或外部人员在存储/修改、检索/使用或传输过程中获取用户数据的途径。考虑可以做些什么来将这些路径减少到最低限度（越少越容易保护和注意模式）。考虑您可以做些什么来使从除极少数点之外的任何其他点获取他们想要的数据变得困难，以及如何保护这些极少点。考虑如何更好地检测批量下载或缓慢的渗透。分层，不要相信单点安全故障，就像你相信单点硬件故障一样。它不会是完美的，但它是一种会得到回报的方法。

这种想法的潜在好处是，即使您的数据库服务器被渗透或内部加密/解密凭据被访问，也许仍然无法如此轻松地获取或窃取大量有用的用户数据。它增加了一个障碍，而且它不需要非常昂贵或复杂。这几乎就是它的原理。

你所描述的似乎是合理的，只要：

• 用户的密码是好的（参见“正确的马电池订书钉”）
• 您正在使用密钥派生函数以合理的方式从密码短语中派生加密密钥（参见PBKDF2）
• 你尽快处理掉钥匙
• 只要用户登录，您就可以阻止任何其他进程复制（备份？、错误的访问权限？、其他任何东西）密钥或解密的数据。