确保密码安全

Question

情况 1 - 将服务器连接到数据库：
它总是说密码不应该以纯文本形式存储，但是连接到 mysql 数据库需要密码，似乎以纯文本形式......我猜最好的解决方案是以加密形式存储它，根据需要在我的应用程序中解密它，然后从内存中删除它（我猜 Windows 中的 SecureZeroMemory 所以编译器无法优化它）。

情况 2 - 用户从远程计算机登录服务器：
至于用户密码，我的计划是根本不实际存储原始密码。 相反，我将为每个用户存储一个随机生成的“盐”，在密码前加上它，然后对其进行哈希处理，这似乎是一种相对常见的方式。 但是我目前没有可用的 SSL 连接，所以我猜测纯文本密码可能会被拦截，对此有什么好的解决方案吗？

有哪些好的算法（如果有的话，C/C++ 实现的链接也很方便）可以做到这一点，在网上一看，有 100 个这样的算法？

编辑：
如果我获得了 SSL，以下内容是否安全（假设使用强哈希算法），或者应该使用不同的方法？

1. 客户端请求用户名的 salt
2. 客户端在密码前添加 salt，然后对其进行哈希处理，然后将哈希值发送到服务器
3. 服务器将收到的哈希值与服务器上该用户名的哈希值进行比较

Answer 1

将服务器连接到数据库

仅将数据库密码存储在服务器中（无论是否加密）都是一个坏主意。 当然，以纯文本形式存储它是显而易见的。 如果你只是加密存储，服务器仍然需要密钥来解码它。 在服务器代码中找到密钥通常并不难。 最好的解决方案是让启动服务器的用户输入密码并将其存储在任何地方。 或者 - 甚至可能更好 - 您可以加密存储所有敏感信息 - 例如数据库用户、密码等，并让启动服务器的用户输入主密钥来解密此信息。

将用户连接到服务器

这确实是一个难题，而且很容易搞砸。 引用这篇很棒的文章关于我绝对推荐阅读的主题。

不，真的。 使用别人的密码系统。 不要构建自己的。

一个好的解决方案可能是使用安全远程密码协议。

Answer 2

您是对的，如果您不使用 SSL，那么密码可能会被拦截。

通常的做法是永远不会解密用户的密码，因此请使用盐对其进行哈希存储，当用户输入密码时，您将添加盐并对其进行哈希处理，将其与存储的哈希密码进行比较。 这将使您永远不会拥有密码的解密版本。

您确实应该考虑保护连接，以便用户输入密码时密码是安全的。

更新以回答已编辑的问题：
如果您使用 SSL 保护通信，您仍然可以使用任意数量的您喜欢的额外安全措施，包括散列密码。 为了增加安全性，最好记住您存储的密码应该使用盐进行散列存储。 该盐应该安全保存，并且除了您的应用程序之外，绝不能在任何地方访问。 这样，当用户提交密码时，您只需添加盐和哈希值，然后将该版本与存储的版本进行比较。

Answer 3

情况 1 - 将服务器连接到数据库

这里没有一个简单的答案。 为了连接，服务器需要密码（或对称密钥，或私钥或其他）。 它必须从磁盘或某种外部方式（例如管理员在启动时键入它）获取它。 添加一些间接方法，例如在主密码下加密所有敏感内容，可以增加一些便利，但不会改变情况。

通常，将密码或密钥放在服务器上的文件中就可以了。 如果执行此操作，请确保设置该文件的权限，以便只有需要该文件的用户才能访问该文件。 这是让系统上的不同进程以不同的用户身份运行，并为每个进程设置单独的角色/帐户和密码的一个很好的理由。

情况 2 - 用户从远程计算机登录服务器

我认为您的方向是正确的。 听起来您要求的是安全身份验证协议。 您需要一种能够提供相互身份验证并防止中间人攻击的方法，如果尝试进行此类攻击，就会失败。 当然有很多可供选择。

还值得考虑的是，您的身份验证是否应该基于“您知道的东西”（密码）或“您拥有的东西”（公钥/私钥）进行操作。 假设根据你的问题，我们正在寻找的是密码，我喜欢的两个是 SRP 和 Kerberos。

前面提到了 SRP，但它并没有得到应有的关注。 SRP 的优点是它不需要服务器知道密码、密钥或攻击者可以用来获取访问权限的任何内容。 如果您使用 SRP 侵入了正确配置的服务器并窃取了所有数据，那么您仍然需要对每个密钥单独执行字典攻击之类的操作，然后才能使用任何东西来模拟用户。

我还喜欢 Kerberos，因为它受到大量软件的支持（我知道 Postgres 支持它，我只发现提到 mysql 不支持任何好的身份验证技术），并且有一个提供单点登录功能的“票据”系统。 Kerberos 需要一些其他技术来帮助加强其初始身份验证交换，SRP 对此非常有用，但我不确定他们是否已经这样做了。 我认为它使 KDC（密钥服务器）具有状态。

Kerberos 的弱点是您必须更加警惕存储密钥的服务器。 虽然它不以明文形式存储密码，但它确实存储密钥，这些密钥本质上是密码的哈希版本。 虽然客户端在身份验证时并不直接发送密码或密钥（毕竟这是真正的身份验证协议），但它确实使用散列密码作为密钥，因此任何了解算法并知道的人都知道钥匙也可以做同样的事情。 我们说服务器存储了“等效密码”。 因此，所有手册都告诉管理员将 kerberos 服务放在各自独立的锁定框中，以最大程度地减少其内容受到损害的可能性。

好处是，一旦您选择了强大的身份验证交换，其他好东西通常会免费出现。 最终双方共享一个共同的“秘密”，该“秘密”可以在会话期间使用一次，永远不会通过网络发送，并且第三方无法知道。 想要加密吗？ 钥匙到了，一切准备就绪，可以出发了。 这正是 RFC 5054 中定义 SRP 安全 SSL 的方式。

Answer 4

较新的 MySQL 通过网络使用散列密码，因此您不必担心中间人。

如果您担心配置文件中存储的密码，可以使用密码对配置文件进行加密。 但是，问题是您必须输入密码才能启动应用程序。

15 年前我编写了一个类似的应用程序。 那时，PGP 是我的选择。 我什至不确定它是否还存在。

Answer 5

不确定这是否是您所要求的。
但是一个使用内置 sha1 函数的简单 PHP 示例：

// Check the hashed password from the database
if (sha1($salt.$password) == $providedPassword)
{
    // User is authenticated
    return TRUE;
}
else
{
    // User is not authenticated    
    return FALSE;
}

您可以做的一件事是在通过网络发送密码之前使用 javascript 对密码进行哈希处理。 问题是客户端和服务器之间如何共享盐字符串？ 一种可能性是使用会话变量。 然后使用会话变量在服务器上对密码进行哈希处理。 这意味着中间的人需要知道另一条信息才能理解密码。 不像 SSL 那样安全，但可能是针对随意网络嗅探者的额外防御层。

我还可以想象一个与某种验证码系统相关联的哈希方案，用于在通过网络发送之前对本地客户端上的密码加盐。 客户端将通过完成验证码来提供盐字符串的文本。 你可以自己查一下。

主要担心的是中间人不理解纯文本密码。

应使用 SSL，但在无法使用 SSL 的情况下，上述技术可能会很有用。