SQL Server可以选择加密应用程序和数据库之间的连接。当您在不受信任的环境中操作 SQL Server 时，建议您启用它。当您这样做时，只要您信任您的数据库管理员，就不需要在将密码发送到数据库之前对其进行哈希处理。

此外，大多数 SQL Server 部署将在 DMZ 中拥有一个应用程序服务器，在 LAN 上拥有一个 SQL Server，这意味着您在受信任的环境中运行。除非你有一个非常高的安全标准，否则没有加密不会有很大的安全风险。

没有人相信。使用安全字符串保存纯文本密码并立即对其进行哈希处理。希望您的系统安全的时代已经一去不复返了。它不是。一个坚定的攻击者可以访问您的系统只是时间/金钱的问题。

即使流量使用 SSL/TLS 加密，我也可以提出几种情况，例如，每种情况都会导致密码泄露

• 政府捕获 SSL 流量并“很好地要求”私钥来解密它。都在专用网络中吗？您确定没有配置异地复制吗？
• 您的组织安装了执行中间人 SSL 解密的硬件，以嗅探通过其网络的 SSL 流量。突然间，更多的人、硬件和软件参与其中——你相信他们吗？它是否尚未安装或尚未安装？
• 持有 SSL 私钥的服务器被黑客入侵，密钥被泄露。私下里。悄悄。
• 一名心怀不满的员工因复制私钥并将其出售给竞争对手而获得报酬

是的，这里有各种风险或风险增加。

首先，无论您的 DBA 是否值得信任，他们都应该能够诚实地告诉任何审计员（或监管调查员或律师），不，他们不可能冒充用户 X，因为他们从来没有能力即使他们想要查看用户 X 的密码，即使他们使用了服务器私钥的副本和数据包嗅探器。

其次，如果您在服务器上散列密码，您应该：

• 阅读规范的如何安全地散列密码？Thomas Pornin 的回答归结为“使用 BCrypt、SCrypt 或 PBDF2”。
  • 在峰值负载下可以处理尽可能多的迭代。
  • 输出长度不超过基本散列原语输出长度。
• 由于这是 SQL Server，请参阅我自己的纯 T-SQL PBKDF2 实现答案。
  • 请注意，与实际实现相比，它的速度非常慢，尤其是像 oclHashcat 这样的攻击实现。
• 当前单机、多 GPU 离线攻击速度见oclHashcat 。这就是攻击者、研究人员和破解竞赛参赛者在从某个前端漏洞或带有数据库备份的笔记本电脑或（在此处选择您最喜欢的场景）中获取您的哈希密码副本后将使用的内容。
• 基于以上所述，意识到无论您的应用程序是什么，在相同的计算时间下，它可以使用比 SQL Server 数据库更多的轮次 BCrypt、SCrypt 或 PBKDF2 来对密码进行哈希处理。
  • 通过横向扩展添加更多前端功能几乎总是比添加更多 SQL Server 功能更容易且更便宜。

请注意，我的 Github 存储库中有各种 PBKDF2 实现，包括基于 Jither 工作的 C# 变体，它是 Jither 在 MIT 许可下发布的。

所以这取决于环境的可信度。如果你对它的信任度为零，也许一些加密会很好。此外，配置的低分支集可能仅限于需要 SQL 连接的主机，尽管有许多不同的原因导致您希望打开它以进行访问。