在 SQL 中存储联系信息时的最佳实践，我应该加密吗？答案

【问题标题】：Best practise when storing contact information in SQL, should I encrypt?在 SQL 中存储联系信息时的最佳实践，我应该加密吗？
【发布时间】：2012-05-23 20:24:16
【问题描述】：

我只是想知道当我将用户联系信息存储在数据库中时是否应该加密它？

例如电子邮件、电话号码等...

【问题讨论】：

对不起，我不明白@MattGibson
@Matt 在问：你为什么要加密？对您的用户有什么好处？值得付出代价吗？如果数据公开会发生什么 - 重要吗？
我现在更新了问题以给出用例。

标签： sql sql-server database encryption

【解决方案1】：

通常您只加密敏感信息，这取决于您的项目要求。如果用户电子邮件或电话号码很敏感，请对其进行加密。另一方面，由于您需要从数据库中获取联系人信息，因此您将使用对称加密，并且很容易解密，因此您在这种情况下的“安全性”只是滥用数据并且不够强大。

无论如何，您应该始终对密码等敏感数据进行加密，我建议使用哈希进行非对称加密。

在我的项目中，我从不需要加密任何联系信息，并且只有密码在数据库中被加密。如果您正在实施 Web 应用程序，我建议您使用安全令牌（基于声明的安全性）并在网络上旅行时对所有联系信息进行加密（通过使用消息或传输安全性），因此泄露任何联系人的风险非常低向第三方提供信息。

【讨论】：

我强烈希望您不要“加密”密码。密码应使用加密强度高且计算密集的哈希函数进行加盐和哈希处理。与加密不同，这些无法逆转。常用函数是 bcrypt、scrypt 或 PBKDF2。
新应用程序应该使用 Argon2id 而不是 bcrypt、scrypt 或 PBKDF2。

【解决方案2】：

我要解决更广泛的问题：我应该加密吗？

在我非常拙劣的看法中，如果信息以任何方式与个人身份相关联并且可以公开访问您的网站或网络，那么答案是肯定的。我将忽略索引和搜索加密信息的技术复杂性，只给你以下思考：

身份和信用卡窃贼，不太可能从一个来源获取您的所有信息。
他们可能会逐个寻找的信息很广泛。姓名，地址、电话、CC 号码和到期日期等...
一旦一个人拥有零散的记录，所有这些信息都可以用于尝试将一个碎片记录与其他。 IE，德克萨斯州加兰市的约翰·史密斯很可能是 1111 Some Dr, Garland, TX。
一旦成功关联，您的数据中就会出现碎片化记录结合MY数据中的零散记录成为一个完整的记录，那么我们客户的生活就一团糟。

这是一条非常简单的路径，而且很多信息都是公开记录的，所以从某种意义上说，保护它是一个有争议的问题。但是，如果您被打官司，并且确实发生了，那么当您每小时向您的律师支付 500 美元时，您可能会感到很不自在。

【讨论】：

【解决方案3】：

仅当您预计您的安全受到威胁或知道不值得信任的人将直接访问您的数据库时，加密联系信息才有意义。

单向加密（散列）将使您的数据无用，因为无法检索它，因此您必须使用某种形式的可逆加密。

在您的数据库中加密联系人信息会有一些缺点，最明显的是：

加密不是免费的，处理数据需要时间
您无法根据部分数据（如部分联系人姓名）搜索加密数据

请注意，可逆加密的弱点在于解密所需的密钥。不要将其存储在同一个数据库中。

使用传输层安全性（如 SSL）更有意义。

【讨论】：

如果您在更换或升级硬件时丢弃了硬盘驱动器，加密也很好。这样，您就不需要监管链和正式的硬盘销毁流程。今天使用 AES-256 的加密几乎是免费的，因为 AES-NI 和足够快的计算即使是最小的企业也很容易获得。
大声笑，是的，自从我 5 年前写下这个答案以来，发生了很多变化。例如，根据 GDPR 和其他隐私法规，我现在默认加密个人信息。特别是在云中操作时，您几乎无法控制物理磁盘或数据库与应用程序之间的网络流量。再说一次，同样的云使应用加密变得如此容易，这几乎是不费吹灰之力。
啊哈，我什至没有注意到这篇文章已经那么老了！感谢您以任何方式回复:)