双键加密/解密？

Question

我希望使用PHP和MySQL存储一些相当敏感的数据，并且将使用某种形式的可逆加密来实现这一点，因为我需要以纯文本形式恢复数据，因为它可以用于任何用途。 / p>

我将从用户的用户名/密码组合中获取加密密钥，但我很难忘记在密码被遗忘的（不可避免的）事件中该怎么做。我意识到加密的目的是只能使用正确的密钥撤消，但这必须在之前解决..

我试图了解公钥加密是否适用于该问题，但我能想到的是私钥仍然需要正确解密数据..

有什么想法吗？

Answer 1

目前尚不清楚你在追求什么，所以关于如何实施它的建议很难。

PGP和S / MIME等标准使用新的对称密钥加密每条消息。然后为每个消息接收者加密这些密钥。这样，每个收件人都可以获得相同的密文而不是复制邮件（可能非常大），而只有密钥（小的）是重复的 - 但每个收件人的加密方式不同。

也许您可以在此处执行类似操作，使用用户密码加密密钥，并使用您的公钥加密另一个副本。如果用户忘记了密码，您可以使用私钥为他们恢复邮件（经过适当的备份身份验证）。

Answer 2

传统解决方案是拥有“恢复代理”：一个用户拥有可用于解密所有数据的第二个密码。严格的使用策略将适用于使用恢复密码，例如将其物理地放入保险箱。

然后，加密所有数据两次：一次使用用户密钥，一次使用恢复密钥;或者，为每组数据生成会话密钥，并仅对数据加密一次，但会话密钥加密两次。

为了实现这一点，至少恢复代理的密钥必须是非对称的，因为私有部分将存在于安全中，而公共密钥则存在于软件中。

使用相同方案的另一种方法是：在密码更改时使用恢复密钥加密用户密码。这更容易实现，但是将允许恢复密码而不仅仅是数据，这可能是不合需要的。

Answer 3

  

我想找一些公平的   使用PHP和MySQL的敏感数据   将使用某种形式的可逆   加密，因为我需要这样做   以纯文本格式返回数据   因为它有用。

保护敏感数据很好。现在：

• 是谁的数据？ （您的，您的用户或第三方？）
• 需要保护什么？ （披露，腐败（偶然或故意......）
• 需要保护谁
  • 不参与的政党不言而喻。
  • 您是否需要/想要避免自己访问明文数据（对于拒绝有用），
  • 您是否需要保护用户的数据不被第三方看到，
  • 或来自用户的第三方数据
  • 或来自用户或第三方的数据？
• 有什么可能的攻击？
  • 在服务器完全受损的情况下，您是否需要保护？
  • 您是否需要防范应用程序级攻击，用户只需访问一些但不是所有可用数据（例如访问SQL数据库，但不访问文件系统）？
  • 数据量是否足够小，攻击者可以猜测并只是检查他/她是否正确？ （短密码，数字，简单单词，固定表格文本可能是候选人）
  • 攻击者是否知道要攻击的明文？
• 如果用户忘记密码，数据是否更好（或重新检索数据）是否更好？或者是否值得增加暴露数据的风险以避免成本？

可能还有其他问题，但这是您在使用加密时想要考虑的事情。答案将帮助您弄清楚您需要什么以及您想要什么，并且可能有助于指出正确的方向。您可能不想与我们分享所有答案。

  

我将导出加密密钥   来自用户的用户名/密码   组合，但我很难过   在（不可避免的）事件中做   密码被遗忘。我意识到   加密的目的是那样的   它只能使用   正确的钥匙，但一定是这样   在...之前解决..

您可能已经决定了解决方案而没有考虑影响。这并不意味着解决方案是错误的，但这个问题表明你应该考虑你愿意为安全带来什么风险。有时数据会有风险。

  

我正试图理解我的想法   是否公钥加密   会适用于这个问题但是我   可以想到的是私钥   仍然需要正确   解密数据..

这听起来像是寻找问题的解决方案。当您有两个（或更多）单独的actor有兴趣在它们之间进行数据通信时，公钥加密非常有用。这些参与者可以是真实的（人）或功能的（系统的组成部分），但如果没有两个参与者，则没有理由拥有单独的公钥和私钥。

Answer 4

基本上，如果你加密了某些东西，并且丢失了加密密钥，你就搞砸了。

在保护数据方面，您需要考虑 为什么保护数据，以及您正在尝试保护它的。为了做到这一点，需要做出哪些权衡取舍 - 唯一真正安全的系统是与互联网完全隔离的系统，这对于大多数应用来说是一种自我挫败的安全级别。

所以这里有一些问题要问自己：

1. 如果有人危及我的数据库，他们是否可以访问此数据？
2. 如果有人妥协我的整个应用程序堆栈怎么办？

如果上述两个问题的答案为“否”，则密钥材料必须由用户持有。如果丢失密钥，他们将无法访问他们的数据。

如果您还拥有一个“主密钥”，而不是存储在应用程序附近 的任何位置，则可以为手动密钥恢复提供一个选项，只有您持有它并使用它来手动重置密码。如果这也不是一个选项（比如，只有用户应该能够访问数据，而不是系统管理员），那么你将不得不在某个地方做出妥协。

Answer 5

这是我自己想过的一个问题，我认为可以使用以下选项（选项＃1最安全）：

1. 不提供重置密码功能 - 如果他们忘记了密码，他们就会被锁定。

2. 生成新的安全主密钥并加密＆amp;使用此主密钥散列用户密钥，并将密文和散列结果存储在数据库中。然后，通过将安全密钥添加到用户下载的文件，通过电子邮件发送给用户或在屏幕上显示安全主密钥，使用户知道安全密钥。要重置密码，用户必须输入此主密钥，然后对其进行散列和比较，如果匹配，则解密数据库中的用户密钥。

3. 要求用户在注册时提供2个安全问题和答案;散列答案并将问题存储在数据库中并回答哈希。第二个答案用作加密用户密钥的主密钥。要接收密码重置请求电子邮件，用户必须正确回答第一个问题。一旦他们点击电子邮件中的链接，网页就会询问第二个问题，如果这是正确的，并且查询字符串参数值有效，则使用第二个问题的答案来解密用户的密钥。

4. 使用应用程序全局主密钥（可能存储在Web / UI应用程序中并使用它来加密和存储用户密钥。一旦通过密码重置电子邮件过程验证用户，用户的密钥将使用应用程序全局主密钥，然后使用新密码重新加密。

总之，每个选项的好处如下：

1. 这是安全的最终目标，如果数据对于保持加密至关重要，则可能是唯一的选择。然而，在现实世界中，人们会忘记密码，因为太阳升起并且没有提供重置密码功能可能是一个糟糕的商业决定。

2. 这是安全的，因为主密钥不存储在前端或数据库中，因此如果平台被泄露，则数据需要花费大量精力才能解密。然而，缺点是用户仍然可能丢失他们的主密钥。

3. 这里的弱点是，如果数据库被泄露，可以研究问题的答案，然后用于解密用户加密密钥。

4. 如果您的平台被黑客攻击，此方法会将应用程序密钥留在堆栈中，从而使您的数据容易受到攻击。您唯一的保护是，如果数据库服务器被黑客入侵，那么数据仍然是安全的。

与软件开发领域的大多数事情一样，您需要考虑什么是最适合您要完成的目标，并寻求正确的平衡。

Answer 6

为什么您为每个用户使用不同的密钥？

如果您选择一个键，则更容易处理。

将加密密钥存储在数据库之外。

您的应用程序仍然必须能够访问它，但是具有数据库转储的人将无法读取加密信息。

Answer 7

1. 生成随机会话密钥。
2. 使用会话密钥加密数据。
3. 使用您需要的任意数量的用户密码加密随机密钥。

这样您就可以使用任何用户密码来解密数据。