C# 和 SQL Server：密码。去哪里做什么？答案

【问题标题】：C# and SQL Server: Passwords. Where to do what?C# 和 SQL Server：密码。去哪里做什么？
【发布时间】：2010-10-03 15:00:08
【问题描述】：

好的，我有一个用 C# 编写的应用程序。我们在 SQL Server 中有数据。在这些数据中，我们有用户帐户，可以访问应用程序。

我已经阅读过，我知道你应该加盐和散列，并可能散列很多次，等等。但是，我在哪里做什么呢？我向 SQL Server 发送什么以及从 SQL Server 发送什么？我到底在数据库中存储了什么？我是否在 SQL 中对其进行哈希处理？（可能有一个散列函数，就像在 mysql 中一样？）我是否在我的代码中散列并做一些花哨的事情？我是将哈希发送到服务器并进行比较，还是从服务器获取哈希并在我的应用程序中进行比较？盐呢？我在哪里做？我在哪里存储它？如何获得？

换句话说，谁能给我一个很好而清晰的登录场景演练（可能还有用户添加/重置密码场景）。什么去哪里，什么应该用在哪里等等。

希望有人能帮我解决这些问题 =)

【问题讨论】：

标签： c# sql-server encryption passwords hash

【解决方案1】：

对于 C# + SQL Server，您可以只使用 MembershipProvider 模型，它会为您处理所有这些。

而 IMO，正确处理所有这些事情的最重要部分是不要自己做。相反，请依赖您的平台提供的机制。以一种似乎起作用的微妙方式很容易出错。然后你进行部署，直到在你被黑客入侵之后，你甚至都不知道有什么问题。

【讨论】：

内置机制看起来就像本地实现一样容易工作。不同之处在于，在您被黑客入侵后，您不知道是您设置错误还是存在一些您不知道的漏洞。
@Spencer：这是我很久以来听到的最荒谬的事情了。
但我认为，使用内置机制，你被黑客入侵的风险要小得多，因为微软的团队比一般团队更关注安全性和安全编程开发商。他们提供者的缺陷虽然可能，但比你的缺陷更不可能......
我也得到了...不要自己做的东西...但是既然我正在申请，我必须自己做一些事情！如果不是，我只会告诉我们的客户使用另一个应用程序并去找另一份工作：p
我并不是说我做这些只是为了做这件事，而是因为它是我们正在制作的应用程序的必要部分......不管你怎么做，或者你使用什么，以某种方式，它必须合并到你的应用程序中，以便它可以使用它:)

【解决方案2】：

如果您使用的是 ASP.NET，那么使用内置的会员功能是轻而易举的实现方式，我建议您采用这种方式。

但是，作为一般性问题，我会在您的本地代码中实现散列，然后只将散列值发送到数据库。对于盐，有很多方法可以做到这一点，您可以创建一个随机盐，或者您可以使用记录 id 或其他方式对值进行加盐。同样，我会在 C# 代码中执行此操作。框架中有一个有用的方法可以做到这一点。

【讨论】：

不使用 ASP.NET。这是一个 C# 常规 WinForms 应用程序。

【解决方案3】：

我完全同意 Joel Coehoorn 的观点，最好的选择是相信别人经过验证的真实实施。但是，如果您决定推出自己的安全实施，那么我的建议如下：

将哈希值和盐值存储在数据库中。
在您自己的代码中生成哈希和盐。这样您就不会将自己绑定到特定的数据库。
永远不要以明文形式通过网络发送密码。我建议从数据库中获取哈希值和盐值，并将其与您根据希望进行身份验证的一方提供的用户名和密码计算得出的值进行比较。

【讨论】：

【解决方案4】：

几年前，在会员提供者模型可用之前，我自己就这样做了。

我们使用 ASP.NET 内置的函数来处理密码的散列；它是 FormsAuthentication 命名空间中的静态方法 HashPasswordForStoringInConfigFile。你给它一个密码和一个加密选项，它会返回散列密码。

我们的流程是： - 从数据库中获取输入用户名的哈希密码。 - 散列输入的密码。 - 他们匹配吗？如果是，请继续，否则登录失败。

修改密码时，我们将hash发送到数据库进行存储；我们没有发送未加密的密码。

而且，我相信，这就是 MembershipProvider 今天在幕后所做的事情。

再次重申，无论您如何进行表单身份验证，最重要的一点是通过安全 (HTTPS) 连接工作。

【讨论】：

您应该可以将整个答案替换为“使用会员提供商”。