C# 存储一个经过良好哈希处理的密码及其哈希处理方法是否危险？

我正在用C#开发一个客户端应用程序，它将与服务器（php页面）进行通信，以获取凭据和一些关键服务。我想知道在客户端的机器上存储经过良好哈希处理的密码是否危险？我所说的“良好散列”是指使用众所周知的安全散列函数的随机种子。在本讨论中，假设源代码是免费的（因为所有二进制文件都可以进行反向工程）

---

我的想法是将用户名和散列密码存储在用户的计算机上，并通过未加密的http连接将此用户名和散列以明文形式发送到服务器进行验证。当然，这不会阻止黑客在不知道源密码的情况下（通过一些代码调整）使用他人的用户名和密码哈希作为自己的用户名和密码哈希

一个恶意的个人能用散列密码和用于产生散列的代码做任何事情吗？（如果获得此信息，则以其他用户身份登录除外）

如果黑客无法访问源密码，其他客户端应用程序如何阻止一个用户以其他用户身份登录？（例如蒸汽）

有没有一种简单、便宜（成本和时间）且更安全的方法来处理这个问题

黑客如何使用我当前的逻辑欺骗他人的登录凭据的示例：

合法用户首次登录时，将存储凭据

黑客获得对文件系统的访问权，找到用户名和散列密码

黑客修改源代码（或使用代码注入）以发送获取的用户名和散列密码，而不是程序通常会执行的操作

---

我生产的产品不会是下一个ebay、facebook或stackexchange，而且是低预算的。我不需要什么一流的东西，也不关心盗窃，因为我计划使用“随心所欲”的模式。我主要是出于好奇才发布这篇文章。

将散列密码存储在用户的计算机上会使他们面临（相当大的）风险——即使访问您的网站不是特别有价值，许多用户也会在许多网站上使用相同的用户名和密码。如果其中任何一个使用与您相同（如您所说，众所周知）的哈希函数，则访问该数据会使攻击者能够访问这些其他网站

对于一个简单、低预算的方法，我会使用一个简单的挑战/响应系统。当用户要求登录时，向他们发送一个随机数字。他们将密码输入客户端程序，客户端程序对其进行散列，并使用散列后的密码作为密钥对随机数进行加密，然后将结果发送到服务器。服务器使用其存储的用户密码哈希来加密相同的随机数。当它从用户那里得到结果时，它会比较两者。当且仅当两个密码匹配时，用户才具有正确的密码

如果您的目的是避免用户必须始终输入密码，请将随机数和加密的随机数存储在他们的计算机上。只要他们收到相同的挑战，他们就可以发送相同的响应。当/如果质询发生更改，他们需要重新输入密码以加密新质询。恢复存储的数据只会让攻击者访问您的站点，而且访问时间相当短（而且尽早更改挑战也很简单）

这完全避免了传输密码（即使是散列形式）。唯一的例外是在初始设置期间，当您需要将哈希密码输入服务器时。为此，您有两种选择，但PK加密可能是最明显的——您向他们发送密钥，他们发送使用该密钥加密的数据。如果其他人截取了数据，那就没用了（当然，除非他们破坏了加密）

---

至于如何生成随机数，通常的方法非常简单：从服务器上的

/dev/random

之类的源代码生成一个真正的随机数。将其（散列版本）用作加密算法的密钥，该算法在计数器模式下运行-即，您有一个计数器（您不必保密），您使用该密钥加密（您确实保密）。每次需要生成新的质询时，您都会增加计数器，对其进行加密并发送结果。

我强烈反对尝试创建自己的身份验证方案。如果您使用经过时间测试的模式，则更有可能覆盖您未考虑的边缘情况。以下是我的建议和原因：

不允许使用哈希值而不是完整密码登录。这样，即使攻击者获取了存储在服务器上的密码散列，他们也无法使用它们登录

尽量避免存储密码，甚至是散列密码。如果您希望轻松登录，@Mitch的建议是一个很好的折衷方案，但我建议您加密即将过期的令牌，并可能将即将过期的令牌绑定到其他证据上（例如，如果使用不同的IP地址发送令牌，则该令牌将失效）

切勿以纯文本形式传输凭据。即使传输的凭证被散列，如果捕获了流量，也可能发生重播攻击。SSL实现起来并不十分困难，它将为您带来额外的好处，即客户端能够验证他们是否与正确的服务器进行了通信，这有助于防止中间人攻击

切勿在服务器上存储用户密码。改为储存一份盐腌土豆条。确保哈希值较大，以降低暴力攻击成功的可能性（例如SHA-256）

我知道你想寻找一种便宜、易于开发的解决方案。与其为了实现这一目标而实施劣质的安全性，不如尝试使用预先构建、经过时间测试的身份验证库。这是一种去萨的方式