源代码管理中的密码存储 [英] Password storage in source control

问题描述

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

We store all our application and db passwords in plain text in source control. We do this as our build/deploy process generates required configuration files and also does actual deploys that require these passwords (ie: running sql against a database requires you logon to the db using valid credentials). Has anyone had a similar need where you were able to implement this type of functionality while not storing the passwords in plain text?

推荐答案

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

If your plan is to store all the code and configuration information to run a production system directly from version control, and without human intervention, you're screwed. Why? This is all just a violation of the old security axiom "never write your password down". Let's do a proof by negation.

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

First cut, you have plain text passwords in the configuration files. That's no good, they can be read by anyone who can see the files.

第二次，我们将加密密码！但是现在代码需要知道如何解密密码，因此您需要将解密密钥放在代码中的某个位置.问题刚刚被推到了一个层次.

Second cut, we'll encrypt the passwords! But now the code needs to know how to decrypt the passwords, so you need to put the decryption key somewhere in the code. The problem has just been pushed down a level.

如何使用公钥/私钥?与密码相同的问题，密钥必须在代码中.

How about using public/private keys? Same problem as the passwords, the key has to be in the code.

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

The use of a local configuration file not stored in version control still puts the password, and the means to read them if they're encrypted, on disk and available to an attacker. You can harden things a little by ensuring that configuration file's permissions are very limited, but should the box be rooted you're screwed.

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

Which brings us to why putting passwords on disk is a bad idea. It violates the concept of a security firewall. One compromised machine containing login information means other machines will be compromised. One poorly maintained machine can tear down your whole organization.

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

At some point a human is going to have to inject the critical secret to start the chain of trust going. What you could do is encrypt all the secrets in the code and then when the system starts up have a human manually enter the key to decrypt all the passwords. This is like the master password system Firefox uses. It is open to abuse since once that one password is compromised, many systems may be compromised, but it is convenient and probably more secure since users only have to remember one password and are less likely to write it down.

最后一步是确保登录信息是否应该被盗用(并且您应该始终假设它会)A)攻击者不能用它做太多事情 B)您可以快速关闭被盗用的帐户.前者意味着只为帐户提供所需的访问权限.例如，如果您的程序只需要从数据库中读取数据，请使用仅限于 SELECT 的帐户登录.通常，删除所有访问权限，然后仅在必要时添加它.对删除权要吝啬，以免您从 little Bobby Tables 访问.

The final touch is to ensure that should the login information be compromised (and you should always assume that it will be) that A) the attacker can't do much with it and B) you can quickly shut down the compromised accounts. The former means to only give the accounts as much access as they need. For example, if your program only ever needs to read from a database have it log in on an account restricted to SELECT. In general, remove all access and then add it only as necessary. Be stingy about the rights to delete lest you get a visit from little Bobby Tables.

后者意味着您为每个用户/组织/项目提供自己的登录信息，即使他们可以拥有完全相同的权利和特权并访问相同的数据.这有点麻烦，但这意味着如果一个系统遭到入侵，您可以快速关闭该帐户，而无需关闭整个业务.

The latter means you give each user/organization/project their own login, even if they can have the exact same rights and privileges and access the same data. It's a bit more of a hassle, but it means that if one system is compromised you can quickly shut down that account without shutting down your whole business.

这篇关于源代码管理中的密码存储的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！