sha1 哈希密码在内存中的安全性答案

【问题标题】：Security of sha1 hashed password in memorysha1 哈希密码在内存中的安全性
【发布时间】：2017-06-05 05:19:14
【问题描述】：

我的程序允许用户输入密码。密码立即使用 sha1 和常量盐进行哈希处理并存储在内存中。假设攻击者对运行我的应用程序的计算机具有物理访问权限，并且想要检索最后一个用户的密码。

他有可能通过逆向工程和一些内存监视魔法找到内存中的哈希吗？我的应用程序使用 MFC 图形界面并在 Windows 上运行。如果他自己输入密码，他会看到什么？他能监控哈希过程吗？

如果我的用户密码真的很糟糕，比如“1234”，那么 SHA1 哈希的所有安全性都取决于 SALT。 salt 还必须存储在内存中的某个位置（现在它是一个#defined char* 数组）。他能通过足够的努力找到它吗？

输入过程：

用户在文本编辑中输入密码。完成后，用户单击“确定”按钮，发出BN_CLICKED 消息，调用OnOK 函数。该函数从编辑字段中获取文本，调用哈希函数，它是（在代码中）另一个库的一部分，所以我认为它必须放在内存中的其他地方。散列字符串也存储在其他地方。如果重要的话，项目结构如下所示：

【问题讨论】：

【解决方案1】：

如果您对 Win32/MFC 应用程序进行反向工程，那么您应该注意到这些数据存储在 .data 部分中，而 const 数据存储在 .rdata 部分中，除非开发人员明确创建了另一个部分来存储这些数据。我使用 OllyDbg 进行逆向工程应用，尽管 IDA 是最好的。现在回答你的问题：

A：是的，可以通过逆向工程在内存中找到哈希。您只需要找到该数据的内存地址即可。任何逆向工程师/黑客都可以在 GetDlgItem/GetDlgItemText 中设置断点，然后捕获输入的密码并监控哈希过程。

如果我的用户密码很糟糕，比如“1234”，那么 SHA1 哈希的所有安全性都取决于 SALT。 salt 还必须存储在内存中的某个位置（现在它是一个#defined char* 数组）。他能通过足够的努力找到它吗？

A：找到 SALT 也需要很少的努力。人们可以轻松地浏览这些部分或使用我上面提到的技术在监视过程的同时调试和找出 SALT。

如果您真的担心保护这些数据，那么您应该考虑使用加密。希望能回答你的问题

【讨论】：

感谢您的回答，阿塞什。如果我没听错的话，每个内存中保存的数据对于攻击者来说都是可读的。我同意。如果我不知道它的值，那么找到存储在内存中某处的恒定加密密钥有多容易？如果很容易，如果我可以从内存中提取密钥，那么任何加密都有什么用？
找到存储在内存中的加密密钥应该不难。通过浏览数据部分进行猜测并不容易，因此逆向工程师必须进行逆向工程并逐步通过反汇编代码才能找到它。找到该密钥的存储位置也不应该是困难的，但如果该密钥被加密，那么黑客将不得不找到一种方法来解密它。我在加密方面没有太多经验，但 Windows 提供了用于加密的 API：msdn.microsoft.com/en-us/library/windows/desktop/… 可能对您有帮助:)
使用后使用SecureZeroMemory函数将char*缓冲区填充为零。