password-protection - 源代码管理中的密码存储

Question

我们将所有应用程序和数据库密码以纯文本形式存储在源代码控制中。我们这样做是因为我们的构建/部署过程会生成所需的配置文件，并且还会执行需要这些密码的实际部署(即:对数据库运行 sql 需要您使用有效凭据登录到数据库)。有没有人有类似的需求，您可以在不以纯文本形式存储密码的情况下实现此类功能？

Answer 1

如果您的计划是存储所有代码和配置信息以直接从版本控制运行生产系统，并且无需人工干预，那么您就完蛋了。为什么？这完全违反了旧的安全公理“永远不要写下你的密码”。让我们做一个否定证明。

首先，您在配置文件中有纯文本密码。这不好，任何可以看到文件的人都可以阅读它们。

第二切，我们将加密密码!但是现在代码需要知道如何解密密码，所以你需要把解密 key 放在代码的某个地方。这个问题刚刚被推低了一个层次。

使用公钥/私钥怎么样？与密码相同的问题， key 必须在代码中。

使用未存储在版本控制中的本地配置文件仍然会将密码以及读取密码的方法(如果它们已加密)放在磁盘上并可供攻击者使用。您可以通过确保配置文件的权限非常有限来稍微强化一下，但是如果该框被 Root ，您就完蛋了。

这让我们明白为什么将密码放在磁盘上是一个坏主意。它违反了安全防火墙的概念。一台包含登录信息的受感染机器意味着其他机器将受到攻击。一台维护不善的机器可能会摧毁您的整个组织。

在某些时候，人类将不得不注入(inject)关键 secret 来启动信任链。您可以做的是加密代码中的所有 secret ，然后在系统启动时让人工手动输入 key 以解密所有密码。这就像 Firefox 使用的主密码系统。它很容易被滥用，因为一旦一个密码被泄露，许多系统可能会被泄露，但它很方便并且可能更安全，因为用户只需要记住一个密码并且不太可能写下来。

最后一点是确保如果登录信息被泄露(并且您应该始终假设它会)，A)攻击者无法使用它并且 B)您可以快速关闭被泄露的帐户。前者意味着只为帐户提供所需的访问权限。例如，如果您的程序只需要从数据库中读取，则让它登录到仅限于 SELECT 的帐户。通常，删除所有访问权限，然后仅在必要时添加。对删除的权利要小气，以免被 little Bobby Tables 访问.

后者意味着您为每个用户/组织/项目提供自己的登录名，即使他们可以拥有完全相同的权限和特权并访问相同的数据。这有点麻烦，但这意味着如果一个系统受到威胁，您可以快速关闭该帐户，而不会关闭您的整个业务。