AES 自己加密密码是否比 SHA1 更安全？

信息安全 加密 密码学 密码 AES
2021-08-19 01:02:35

这不是一个真正的实际问题，而是一个好奇的问题。我听说一位 CS 教授建议从 md5ing 密码升级到 SHA1，而不是使用 AES 加密密码，使用自身作为密钥。有没有人知道这实际上或多或少是安全的？

关于这个问题的一些想法：

  • SHA1 是单向的，这应该比保留数据的函数更安全。
  • 另一方面，黑客不可能利用 AES 的可解密特性，因为他还不知道密码。
  • 除非他猜到。但是无论我如何加密它，他都会在里面。
  • 由于您知道当解密密钥与输出匹配时，AES 的密码被解密，因此它可能会在黑客的计算机上被暴力破解。
  • 但黑客不知道它是如何加密的，所以他不会尝试那样做。
  • 但黑客也可能获得了加密代码，在这种情况下，这只是一个问题，即哪些数据需要更长的时间才能暴力破解。
  • 大多数网站使用 md5 或 sha1（对吗？），因此这些哈希的查找表将比 AES 方法更广泛。从而使AES方法更加安全。
  • 但是，如果我们对这两种方法都加盐，它们将同样不受查找表的影响。

答案中的一些共同点和反点：

AES 加密并非旨在抗冲突，因此对于相同的哈希字符串长度可能会有更多的冲突。

如果我们使用更长的盐，那么加密密码将比 SHA1 哈希长。这可能足以将碰撞降低到可比较的水平 - 或者可能不会。

AES 加密告诉您密码有多长，在 16 个字节内。

我们可以添加到 AES 方法：加密后，我们填充或修剪到合理的长度（比 SHA1 的长以避免冲突）。

4个回答

简短的回答：坏主意，不要这样做。

更长的答案：练习的重点是存储允许服务器验证给定密码但不允许它重建密码的东西；后一个属性是可取的，因此攻击者对服务器数据库的非法读取访问的后果仍然有限。

因此，我们需要一种单向确定性转换，将给定的密码转换为验证值。变换应为：

  • 可配置的慢速，以阻止字典攻击；
  • 每个实例都不同，以防止并行字典攻击，包括预先计算的表（这就是盐的含义）。

在两个帐户上单次调用 MD5 或 SHA-1 都会失败，因为这些函数非常快，而且没有加盐。缓慢可以通过嵌套许多调用（数千，可能数百万）来完成，并且可以在“某处”注入盐，尽管有好的和坏的方法可以做到这一点。PBKDF2是一个标准的转换，它就是这样做的，而且它并不差（尽管bcrypt 应该更可取）。

但是，MD5 和 SHA-1 至少做对了一件事：它们被设计为单向的。这很难做到；甚至理论上都没有证明单向函数是否真的存在。世界各地的密码学家目前都在参与设计一种新的、更好的单向哈希函数的竞赛。

因此，您的教授似乎建议将专为单向设计的功能替换为不是为单向设计的功能。它并没有纠正任何关于缓慢和加盐的问题，但它消除了关于 MD5 和 SHA-1 的一件好事。此外，众所周知，AES在相关密钥攻击方面相对较弱——这不是问题，只要 AES 用于其本来的用途，即加密，但当它被颠覆时，它就成为一个重要问题。单向哈希函数的构建块。似乎可以通过重用部分 AES 设计来构建安全的散列函数，但它需要大量的改造（例如，参见Whirlpool和ECHO）。

所以不要使用自制的基于 AES 的密码散列方案；就此而言，不要使用任何“自制”的东西：那是灾难的根源。安全性无法测试；制作安全算法的唯一已知方法是让数百名训练有素的密码学家仔细研究几年。你不能自己做到这一点。即使是孤独的密码学家也不会冒险。

相反，使用 bcrypt。PBKDF2 也不错。

大多数网站使用 md5 或 sha1（对吗？），所以这是黑客所期望的。从而使AES方法更加安全。

即使大多数网站使用 MD5 或 SHA1，仅仅因为它通常不在那里使用而切换到 AES 也不会使其更安全——这只是默默无闻的安全，这通常不会有效地提高安全性；使用一个好的算法（针对给定目的经过充分测试）并公开记录它会比使用一个你不能确定它是否好的算法更安全，而不是说你是使用它。

目前，在使用 AES 或任何其他类似的加密算法时，我可以想到以下可能的缺点：

  1. 加密算法通常不是为避免冲突而设计的：正如下面的评论中所指出的，由于分组密码的预期伪随机行为，它可能不是问题。但是，您仍然在使用加密算法来处理它不是为它设计的东西。
  2. 可以想象，如果知道明文和密码实际上是相同的，那么对加密算法的攻击就容易得多（如果您正在使用的算法的事实以某种方式泄漏，这不太可能）例如在这里讨论）。
  3. 加密算法产生的数据在许多情况下会随着明文的长度而变化。这意味着，密文包含有关密码长度的信息。在 AES 的情况下，据我所知，这是 16 个字节的倍数；另一方面，哈希值具有固定大小（例如 SHA1 为 160 位 / 20 字节）；这意味着潜在的黑客有机会从加密文本中获取比哈希值更多的信息。
  4. 在密码学中，与使用经过良好测试并且已经在社区中长期使用的东西（意味着它有时间进行彻底检查）相比，自己制作一些东西（随后可能也只由你使用）通常总是不太安全由许多密码分析家）。
  5. 您希望确保您的密码散列算法速度较慢，从而阻止潜在的攻击者暴力破解进入您的系统。实现这一点的一种方法是例如在多轮中迭代地执行散列，例如 PKBDF2 所做的那样。有关更多详细信息，请参阅http://security.blogoverflow.com/2013/09/about-secure-password-hashing/

我用这种方法看到的一个直接问题是 AES 的固定密钥长度。使用 AES-128，密码将被限制为 16 个字节。更长的密码或长密码呢？

为了适应任何密码长度，您需要一个哈希函数，所以回到初始点。

请注意，有一些经过充分研究且安全*的方法可以将分组密码转换为哈希函数，即 Davies-Meyer、Matyas-Meyer-Oseas 或 Miyaguchi-Preneel 等所谓的 PGV 模式。

(*) 对于“安全”的适当定义。

但是，考虑一下：

我闯入您的网站并获得足够的访问权限以注意到您已为您的系统配置了 AES 密钥，唯一看起来“加密”的是您的密码......猜猜我要做什么。

我会让它们保持散列，为轻松抓取整个密码数据库留下更少的空间。

最重要的是，作为网站所有者，我不希望一开始就能够解密用户的密码，否则“恢复密码”的选项将成为上级可能要求的功能，从技术上讲，我们可以这样做是因为底层系统是使用加密系统而不是散列系统构建的（这是一个蹩脚的原因，但软件开发人员会处理此类请求）。

主要是：当涉及到安全性时，不要试图做一些古怪和开箱即用的事情，你可能会给自己写一个巨大的安全漏洞，因为你无法将大量的研究投入到一个研究算法的团队中出于特定目的将不得不。

其它你可能感兴趣的问题
上一篇有没有办法阻止某人为我的网络服务制作自己的客户端应用程序？ 下一篇如何去混淆可疑的 JavaScript 代码？