如何验证应用程序是否是其所说的应用程序？
情况是这样的：我们有一个公共库，可以从我们设置的中央配置存储中检索数据库连接详细信息。 每个应用程序在使用数据库时都使用此库。
基本上，它将调用一个存储过程并说“我是 {xyz} 应用程序，我需要连接 o ”，它将返回该应用程序主数据库的连接详细信息（服务器、实例、数据库、用户和密码）。
如何锁定它，以便只有应用程序 {xyz} 可以检索 {xyz} 数据库的密码（每个应用程序都有一个数据库详细信息列表......我只需要保护密码）？
Here's the situation: we have a common library which can retrieve database connection details from a central configuration store that we have setup. Each application uses this library when working with a database.
Basically, it will call a stored procedure and say "I am {xyz} application, I need to connect o " and it will return the connection details for that applications primary database (server, instance, database, user, and password).
How would one go about locking that down so that only application {xyz} can retrieve the passwords for {xyz} databases (there is a list of database details for each application... i just need to secure the passwords)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
通常的方法是每个应用程序有一个不同的配置存储，并为每个应用程序提供不同的用户/密码来连接到配置存储。
这并不能阻止任何人更改应用程序并将应用程序 X 的用户/密码替换为应用程序 Y 中的值，但它更安全，特别是当您编译此数据而不是通过配置文件提供它时。
如果你想真正安全，你必须首先创建到存储的安全连接（因此你需要一个支持此的数据库驱动程序）。 此连接必须使用每个应用程序唯一且可以验证的安全密钥创建（因此没有人可以复制它们）。 您需要使用哈希值来保护可执行文件（应用程序将以某种方式计算自己的哈希值并将其发送到服务器，服务器将拥有每个应用程序的有效哈希值列表）。
总而言之，这并不是一件微不足道的事情，您只需使用一个不起眼的选项即可将其打开。 首先，您需要了解很多有关安全性和安全数据交换的知识。 您需要一种方法来将应用程序安全地安装在不安全的地方，验证其完整性，保护代码免受可以在运行时附加的调试器以及在虚拟机中运行的代码的影响，等等。
The usual way is to have a different config store per app and give each app a different user/password to connect to the config store.
That doesn't prevent anyone from changing the app and replacing the user/password for app X with the values from app Y but it's a bit more secure, especially when you compile this data in instead of supplying it via a config file.
If you want to be really secure, you must first create a secure connection to the store (so you need a DB drivers that supports this). This connection must be created using a secure key that is unique per application and which can be verified (so no one can just copy them around). You will need to secure the executable with hashes (the app will calculate its own hash somehow and send that to the server who will have a list of valid hashes for each app).
All in all, it's not something trivial which you can just turn on with an obscure option. You will need to learn a lot about security and secure data exchange, first. You'll need a way to safely install your app in an insecure place, verify its integrity, protect the code against debuggers that can be attached at runtime and against it running in the virtual machine, etc.
我突然想到尝试 PKI。
Off the top of my head, try PKI.
最简单/最直接的方法是以加密格式存储密码（无论如何，以明文形式存储密码是很糟糕的，正如最近在 PerlMonks 中演示的那样），并让每个应用程序负责自己的密码加密/解密。 这样，一个应用程序是否检索到另一个应用程序的密码就无关紧要了，因为它仍然无法解密它们。
The simplest/most straightforward way would be to store the passwords in encrypted format (storing passwords in plaintext is just plain bad anyhow, as recently demonstrated over at PerlMonks) and make each application responsible for doing its own password encryption/decryption. It would then not matter whether an app retrieved another app's passwords, as it would still be unable to decrypt them.
您是否试图保护自己免受恶意程序的侵害？这是这些应用程序连接到的中央数据库吗？ 如果是这样，您可能应该考虑在数据库和应用程序之间建立一个中间层。
我不确定这是否适用于您的情况，具体取决于您对上述问题的回答如何，但通过评论，听起来您的情况与这个问题的情况类似。
保护 C# 应用程序中的数据层
Are you trying to protected yourself from malicous programs, and is this a central database that these applications are connecting to? If so you should probably consider a middle layer between your database and application.
I'm not sure this applies to your case, depending on how what your answers to the abovementioned would be, but by the comments it sounds like you are having a similar case to what this question is about.
Securing your Data Layer in a C# Application
一种可能性是以加密形式将密码保存在数据库中，并通过安全连接将加密密钥传送给允许的应用程序。然后，只有拥有加密密钥的应用程序才能真正获取密码，而其他应用程序则无法获取密码。
One possibility is to keep the passwords in the database in an encrypted form, and convey the encryption key to the allowed application(s) in a secure connection.Then, only the application with the encryption key can actually get the passwords and not others.