这个安全/加密方案安全吗？

Question

我正在推出我自己的、个人的、类似于“云中加密数据”的webapp (我不喜欢UI，也没有非浏览器的客户端)。

然而，我绝对没有安全和加密方面的经验，并且在阅读了.NET密码库的三种安全性、维基百科文章和文档之后，拼凑出了这个方案。

在讨论我的方案之前，下面简要介绍一下我如何理解三格安全方案：它们使用从明文用户凭据派生的密钥对客户机上的数据进行加密和解密，并且只向服务器发送加密的数据。对于身份验证，它们使用与明文用户凭据无关的散列。由于从理论上讲，存储在服务器上用于检索数据的凭据不能用于实际解密数据，因此没有人，甚至服务器所有者和客户程序员也不能解密这些数据，除非他们从用户那里获得原始明文凭据。

假设他们有正确的想法，并且这样的设置确实保证了数据的安全(只要用户的密码不被键盘记录器破坏，用户不会在某个地方以明文形式保存密码，等等)，我想知道我的实现是否完成了这项工作。

发送加密数据的过程是：

1. 用户向客户端输入明文用户名、密码和数据。
2. 用户通过发送明文用户名和密码的SHA-256散列来注册或登录到服务器。每个散列都是用一个5字节的盐进行盐化的。
3. 客户端用gzip压缩数据，然后使用AES-256对其进行加密；256位(256/8字节)密钥是从明文密码派生的，使用的是使用8字节盐*的PBKDF2，而且确切地说是11368圈。IV是由库类自动生成的，我将它添加到加密的数据中，以供以后检索。
4. 加密数据被编码为Base 64字符串，并通过HTTP发送到服务器，因为如果数据已经加密，那么谁需要HTTPS呢？
5. 客户机可以自由检索Base 64数据、对其进行解码、解密、解压缩并以原始明文形式返回--只要他们能够为解密密钥提供明文密码。

*对于N字节盐，我取我想要的明文的未加盐的SHA-512散列(或者我想提供给接受盐的算法的明文)，并从中选择一个确定的N字节子集(例如，对于一个3字节的盐，未加盐的散列的第1、第3和第5字节-对此更好吗？)--字节序列就是我的盐。

如果有关系，我使用的是.NET Framework4，System.Security.Cryptography类。我只编程地为它们的PBKDF2实现指定了回合数，因为这是我看到一个明显的属性/方法来设置它的唯一情况。不过，我认为这一级别的细节对于Stack溢出来说是个问题。

无论如何，我更关心的是绝对的、概念性的安全性，而不是快速计算，但我也很乐意接受任何提高效率的建议(如果我做的任何事情都是多余的)。

Answer 1

“我绝对没有安全和加密方面的经验。”考虑到这句话，如果安全性对您的应用程序很重要，那么设计新的密码方案可能不是最好的主意。密码系统的设计是一个棘手的课题。那些试图在不了解该领域的情况下自行发明计划的人，往往会犯一些不明显的错误。如果我能用一个比喻，我就不会试图给自己做手术，我会去找一位合格的外科医生。如果安全性很重要，您也应该这样做。

关于您的计划:它肯定有一些积极的方面，但也有一些我发现的重大缺点(不能保证这个列表是详尽无遗的)：

• 翻开自己的密室。作为一个非常普遍的评论，密码学史上的第一课是滚动自己的密码是非常容易出错的。。这是一个特别危险的因素，如果你没有深入研究该地区。因此，你正在滑冰，你应该期待你的计划可能会有安全问题，这是你没有预料到的。
• 泄露密码。用户密码往往没有熵。因此，减少或消除针对密码进行脱机字典搜索的机会是至关重要的。使用PBKDF2是个好主意，但是您可以通过向服务器发送密码的(普通)散列来自尽。支持快速脱机字典搜索。而且没有必要这样做。您不应该向服务器发送密码哈希。例如，只向服务器发送用户名就足够了(而不是从密码派生的任何内容)。
• 没有足够的PBKDF2迭代来保护密码。此外，我怀疑PBKDF2的11368次迭代不足以防止字典搜索攻击。最佳实践是选择一个足够大的数字，使操作花费，例如，1秒。参见，例如，关于IT安全的问题。
• 不安全的盐渍。你用来生产盐的计划完全失败了。您正在使用密码的确定性函数作为salt；这完全违背了盐的目的。。盐应该是一个加密强度的随机值，比如长度为64位或更长的。
• 不验证数据。对数据进行加密，但不对其进行验证。如果没有身份验证，攻击者可以篡改数据，您将无法检测到它。此外，出于微妙的原因，没有身份验证的加密是不安全的。。修正:加密后，您应该使用强消息身份验证代码(例如，AES-CMAC)计算密文上的MAC并追加MAC。解密前，你应该检查MAC。不要在加密和MAC中使用相同的密钥；当您从密码派生密钥时，您应该派生两个独立的密钥(256位)。
• 不使用HTTPS。我建议使用HTTPS。加密和身份验证只对某些威胁进行防御。例如，它们不能确保您获得最新版本的数据。这意味着，在您的方案中，如果客户端通过开放的无线连接(例如)连接到Internet，则中间人攻击者可能会进行重放攻击，重放旧版本的数据。我建议您通过HTTPS连接到服务器。
• 可能会受到交通分析的影响。加密并不隐藏正在加密的数据的长度。此外，在压缩数据时，压缩数据的长度可能会显示一些关于正在压缩的数据本身的信息(而不仅仅是压缩数据的长度)，即可能会带来额外的风险。这些风险可能是可以接受的，也可能是不可避免的，但您需要在特定应用程序的上下文中以及通常存储的数据类型中分析它们。

即使您修复了所有这些问题，也不能保证结果是充分安全的。一般来说，如果对一个设计的初步审查表明有4个问题，即使你解决了你所知道的问题，人们也应该非常怀疑:你怎么知道没有第五个问题是你刚刚错过的？

也就是说，在你的设计中也有一些积极的因素。例如，您正在使用标准的经过良好审查的算法，这是很好的。总的来说，我认为你走在一条合理的道路上--有些不明显的问题你可能没有预料到。