如何使用 Delphi 创建视觉挑战/响应以恢复对应用程序的访问？
我有兴趣在 Delphi 中创建挑战/响应类型流程。场景是这样的...我们有 2 台计算机...1 台属于用户，1 台属于支持技术人员。
用户被锁定在某个程序之外，为了获得 1 次访问权限，我希望：
- 向用户显示一个挑战短语，例如“28394LDJA9281DHQ”或某种类型的合理唯一值
- 用户将致电支持人员并读取此质询（在支持人员验证其身份后）
- 支持人员会将此质询值输入到其系统上的程序中，该程序将生成响应，该响应与响应同样独特，例如“9232KLSDF92SD”
- 用户键入在响应中，程序确定这是否是有效的响应。
- 如果是，则授予用户 1 次访问该应用程序的权限。
现在，我的问题是如何做到这一点？我将拥有 2 个应用程序，它们无法相互进行网络访问。 Windows 中是否有任何功能可以帮助我完成此任务？
我相信我可以使用 CryptoAPI 中的某些功能，但我确实是这样不确定从哪里开始。如果您能提供任何帮助，我将不胜感激。
I'm interested in creating a challenge / response type process in Delphi. The scenario is this...we have 2 computers...1 belongs to the user and 1 belongs to a support technician.
The user is locked out of a certain program, and in order to gain 1 time access, I want:
- The user to be presented with a challenge phrase, such as "28394LDJA9281DHQ" or some type of reasonably unique value
- The user will call support staff and read this challenge (after the support staff has validated their identity)
- The support person will type this challenge value into a program on their system which will generate a response, something equally as unique as the response, such as "9232KLSDF92SD"
- The user types in the response and the program determines whether or not this is a valid response.
- If it is, the user is granted 1 time access to the application.
Now, how to do this is my question? I will have 2 applications that will not have networked access to one another. Is there any functionality within Windows that can help me with this task?
I believe that I can use some functionality within CryptoAPI, but I really am not certain where to begin. I'd appreciate any help you could offer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我将实现基于 MD5 的质询响应身份验证。
来自维基百科http://en.wikipedia.org/wiki/CRAM- MD5
此外，您可以在质询字符串中添加一些应用程序标识，以便对质询的发送者进行双重检查。
重要提示：它有一些弱点，请仔细评估它们可能如何影响您。
I would implement a MD5 based Challenge-Response authentication.
From wikipedia http://en.wikipedia.org/wiki/CRAM-MD5
Additionally, you may add some application-identification into the challenge string, for a double check on the sender of the challenge.
Important: it has some weaknesses, evaluate carefully how they may affect you.
关于口头挑战/响应策略：十多年来，我们使用这种方法在全球 5000 个工作站上授权了一个利基应用程序。我们的支持团队将其称为“导弹发射代码”，因为它与老电影中看到的经典导弹发射验证过程相似。
这是保护程序的一种极其耗时的方法。它消耗了我们的员工和客户大量的时间来读取用户的代码。他们都讨厌它。
您的情况/环境可能有所不同。也许您不会像我们一样频繁地使用它。但这里有一些建议：
仔细考虑代码的长度和内容：大多数用户（和支持人员）讨厌输入大量字符。许多用户都是糟糕的打字员。考虑一下与添加的安全性相比，长字符串以及包含标点符号和区分大小写是否会给他们带来过度的负担。
在使用口头质询/响应实现多年之后，我们将其保留在原处（作为后备），但添加了一个简单的自动化系统。我们选择使用 FTP 而不是更复杂的 Web 方法，这样我们就不必在内部服务器上运行任何软件（或与我们的 IT 人员打交道！）
基本上，我们使用 FTP 文件进行交换之前是在手机上完成的。服务器将包含质询短语的文件放置在 FTP 服务器上。文件的名称是客户的姓名。我们的支持人员有一个程序可以在我们的 ftp 站点上自动创建此文件。
我们的工作人员指示客户按下热键来读取 FTP 文件、对其进行身份验证并将响应文件放回到服务器上。
我们的支持人员的软件一直在轮询等待客户的软件创建响应文件。当它看到该文件时，它会下载该文件并确认其内容，然后将其从服务器中删除。
当然，为了实现您的目标，您可以在给定的会话中根据需要在任意方向进行多次这种交流。
文件中的数据可以具有与您口头使用的相同的 MD5 密钥，因此它像您希望的那样安全。
该系统的一个弱点是用户必须具有 FTP 访问权限。我们发现我们的大多数用户（所有企业）都可以使用 FTP 访问。 （当然，您的客户群可能不会...）如果我们在现场的应用程序无法访问我们的 FTP 站点，它会明确宣布该问题，以便我们的客户可以去找他们的 IT 人员请求他们打开访问权限。与此同时，我们又回到了语言规范。
我们使用普通的 Indy FTP 工具没有任何问题。
毫无疑问，这种方法存在一些弱点（可能包括一些我们没有想到的弱点）。但是，对于我们的需求来说，它非常棒。我们的支持人员和客户都喜欢它。
抱歉，如果这些都与您无关。希望这对您有所帮助。
Regarding the verbal challenge/response strategy: We used this approach to license a niche application on five thousand workstations world-wide for more than ten years. Our support team called it the "Missile Launch Codes" because of its similarity to the classic missile launch authentication process seen on old movies.
This is an extremely time consuming way to protect your program. It consumed enormous amounts of our staffs' and customers' time reading the codes to and from users. They all hated it.
Your situation/context may be different. Perhaps you won't be using it nearly as frequently as we did. But here are some suggestions:
Carefully consider the length and contents of the code: most users (and support staff) resent typing lots of characters. Many users are bad typists. Consider whether a long string and including punctuation marks and case sensitivity unduly burdens them compared to the amount of security added.
After years of using a verbal challenge/response implementation, we left it in place (as a fall-back) but added a simple automated system. We chose to use FTP rather than a more sophisticated web approach so that we didn't have to have any software running on our in-house server (or deal with our IT staff!)
Basically, we use FTP files to do the exchange that was previously done on the phone. The server places a file on the FTP server containing the challenge phrase. The file's name is the customer's name. Our support staff have a program that automatically creates this file on our ftp site.
The customer is instructed by our staff to hit a hot key that reads the FTP file, authenticates it, and places a response file back on the server.
Our support staffs' software has been polling waiting for the customer's software to create the response file. When it sees the file, it downloads it and confirms its contents, and deletes it from the server.
You can of course have this exchange happen as many times and in either direction as you need in a given session in order to accomplish your goals.
The data in the files can have the same MD5 keys that you would use verbally, so that it is as secure as you'd like.
A weakness in this system is that the user has to have FTP access. We've found that the majority of our users (all businesses) have FTP access available. (Of course, your customer base may not...) If our application in the field is unable to access our FTP site, it clearly announces the problem so that our customer can go to their IT staff to request that they open the access. Meanwhile, we just fall back to the verbal codes.
We used the plain vanilla Indy FTP tools with no problem.
No doubt there are some weaknesses in this approach (probably including some that we haven't thought of.) But, for our needs, it has been fantastic. Our support staff and customers love it.
Sorry if none of this is relevant to you. Hope this helps you some.