如何在应用程序配置中管理密码
我正在开发一个与许多外部系统 API 交互的系统。其中大多数都需要某种形式的身份验证。为了可用性，有一个“应用程序范围内可访问”的 AppConfig，用于存储配置信息以及外部系统的凭据。
我的问题是，将用户名和密码（以明文形式）存储到应用程序配置文件中的外部系统是否是一个坏主意。如果是这样，你如何避免它？
为了访问配置文件，您要么必须破坏服务器的文件系统，要么破坏另一台服务器（或者当然是任何开发人员的系统）上的 git 存储库。我一直认为对配置文件中的密码进行加密并不会提高安全级别，因为加密密钥也必须存储在某个地方。我这件事有错吗？
我非常感谢解释您如何解决此问题的答案。
解决方案
好的，这是我的最终解决方案。我使用 OpenSSL 创建了一个简单的库来加密和解密我的敏感数据。加载配置时会从用户处检索密钥，但在生产服务器上除外，密钥存储在文件中。它仍然不是最佳解决方案，但它比我之前的“解决方案”要好得多。
谢谢您的回答。我会接受韦恩的回答，因为它提供了最多的信息。
I'm working on a system that interacts with many external system API:s. Most of them require authentication of some sort. For the sake of usability there is an "application wide reachable" AppConfig that stores configuration info, as well as credentials for the external systems.
My question is if it is a bad idea to store usernames and passwords (in cleartext) to the external systems in the application configuration file. If so, how do you avoid it?
In order to access the configuration file you either have to compromise the server's file system, or the git repository on another server (or, of course any developer's system). I'm been thinking that encrypting the password in the configuration file does not increase the security level, as the encryption key has to be stored somewhere as well. Am I wrong about this?
I would really appreciate answers explaining how you have solved this issue.
Solution
Ok, so here is my final solution. I created a simple library using OpenSSL to encrypt and decrypt my sensitive data. The key is retrieved from the user when the configuration is loaded, except on the production servers where it is stored in file. It is still not an optimal solution, but it is way better than the "solution" I previously had.
Thank you for your answers. I will accept Wayne's answer as it was the most informative.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
良好的安全性很难。
正如 Bruce Schneier 所说，“安全是一种权衡。”您必须决定您希望此信息的安全程度，以及您希望花费多少时间来保护所述信息。而且您绝对不想将密码以纯文本形式保留在那里，这是一个禁忌。如果您处于这样的情况，那么您就处于不应该进行用户身份验证的情况。
尽管安全性很困难，但您可以做一些事情。
1）使用某种类型的编译程序来进行加密/解密。您不希望有人打开 Python/perl 脚本并说“啊哈，这只是一个简单的 XYZ 加密”，尽管理想情况下您不需要简单的加密。
2）通过隐匿性实现的安全并不是真正的安全，但它可以帮助防止随意窥探。例如，将文件命名为“passwords.txt”并不是一个非常好的主意，但加密您的密码，然后使用隐写术在某些图像文件中隐藏用户/密码会更好。
3）查找强大的加密/解密算法。其中一些已经在大多数语言中实现，您只需导入库即可。这可能是坏事，也可能是好事，具体取决于您认为自己想要这些东西的安全程度。
但老实说，这个系统在安全方面确实很糟糕。理想情况下，您有两方身份验证，然后由受信任的中间人完成所有的兜售和交易。例如，当您登录计算机时，您就告诉计算机您是授权用户。从那里您可以运行所有程序，他们不会询问或关心您的用户/通行证组合 - 只是您是授权用户。他们从操作系统（中间人）获取此信息。哎呀，即使是 SO 也使用 openID 来确定您是受信任的用户 - 他们不关心您在其他网站上的凭据是什么，只关心其他网站说“是的，这是一个有效的用户”。
如果您可以选择，我会认真考虑切换您的身份验证模型。如果没有，祝你好运。
Good security is hard.
As Bruce Schneier says, "Security is a tradeoff." You have to decide how secure you want this information, and how much time you want to spend securing said information. And you definitely don't want to leave passwords just sitting out there in plain text, that's a no-no. If you're in a situation where that's OK you're in a situation where you shouldn't have user authentication.
Even though security is hard, there are a few things you can do.
1) Use some type of compiled program to do the encryption/decryption. You don't want someone to open up a Python/perl script and say "aha, this is just a simple XYZ encryption", though ideally you don't want a simple encryption.
2) Security through obscurity is not real security, but it can help against the casual snoop. For instance, naming your file "passwords.txt" is not a terribly good idea, but encrypting your passwords and then using steganography to hide the user/pass in some image file is better.
3) Look up strong encryption/decryption algorithms. Some of them are already implemented in most languages and you can just import a library. This can either be bad or good, depending on how secure you think you want this stuff.
But honestly, this system is really bad - security wise. Ideally you have a two-party authentication and then the trusted middleman does all the wheeling and dealing. For instance, when you log onto your computer you're telling the computer that you're an authorized user. From there you get to run all of your programs and they don't ask or care about your user/pass combination - just that you're an authorized user. They get this information from the OS (the middle-man). Heck, even SO uses openID to decide that you're a trusted user - they don't care what your credentials are on the other sites, only that the other sites say "Yes yes, this is a valid user."
If you have the option, I would seriously consider switching your authentication model. If not, good luck.
关于实际示例，Web 服务器以纯文本形式将数据库登录详细信息存储在服务器上。如果有人访问了您的服务器，无论如何您都会被搞砸。但是，为了保护这些密码免受不受欢迎的机会主义入侵者的侵害，我个人喜欢额外的一层，这样会感觉更安全。安全总比后悔好，对吧？
由于这些密码用于外部系统，因此谨慎的做法是使用另一层加密来保护这些密码。是的，通过默默无闻实现的安全性很糟糕，但是您不认为如果有人不得不偶然发现它们，它可以起到很好的威慑作用 - 纯文本密码只是乞求被盗取。
我建议使用 1024 位加密，有一些很好的算法。我还建议对您加密的每个条目使用 64/128 位随机盐，这样即使一个条目的密码被暴力破解，该解决方案也不适用于其他条目。随机加盐可以防止彩虹表攻击，这会迫使您的破解者使用暴力，这会更加耗时。
是的，这些预防措施看起来有些偏执，但如果我尝试破解自己的密码（当然是为了研究兴趣），我可以想象一些恶意的人可能会尝试什么。
编辑： 盐如何使加密更安全的示例，即使加密密钥已知。
Regarding real live examples, web servers store database login details on the server, in plain text. If someone gains access to your server, you are screwed anyway. But protecting those passwords from the unwanted opportunistic intruder, well personally I like the extra layer to feel safer. Better safe than sorry, right?
Since these passwords are for external systems, it would be prudent to secure those with another layer: encryption. Yes security through obscurity is bad, but don't you think it acts as an excellent deterrent if someone had to stumble onto them - Plain text passwords just beg to be taken.
I recommend using 1024 bit encryption, there's a couple good algorhytms. I also recommend using a 64/128 bit random salt for every entry you encrypt, so that even if the password for one entry is brute-forced, the solution won't work on other entries. Random Salting prevents Rainbow table attacks, which forces your cracker to use brute force, much more time consuming.
Yes these precautions seem paranoid, but if I try and crack my own passwords (for research interest, of course) I can imagine what some malicious minded person might try.
Edit: An example of how the salt makes encryption more secure, even if the encryption key is known.
一些 webbserver 需要在启动时加载对称加密的证书。为了解决这个问题，他们要求在启动时输入密码。这样它就只存储在内存中。
优点：
ps Fax中提取主密码。缺点：
Some webbservers need to load symmetrically encrypted certificates on startup. To deal with this, they ask for password input on startup. So that it is only stored in memory.
Pros:
ps fax.Cons: