5

我有兴趣在 Delphi 中创建一个挑战/响应类型的过程。场景是这样的……我们有 2 台计算机……1 台属于用户，1 台属于支持技术人员。

用户被锁定在某个程序之外，为了获得 1 次访问权限，我想要：

  1. 向用户呈现一个挑战短语，例如“28394LDJA9281DHQ”或某种类型的合理唯一值
  2. 用户将致电支持人员并阅读此挑战（在支持人员验证其身份后）
  3. 支持人员将此挑战值输入到他们系统上的程序中，该程序将生成响应，该响应与响应一样独特，例如“9232KLSDF92SD”
  4. 用户输入响应，程序确定这是否是有效响应。
  5. 如果是，则授予用户 1 次访问应用程序的权限。

现在，如何做到这一点是我的问题？我将有 2 个应用程序彼此之间无法联网访问。Windows 中是否有任何功能可以帮助我完成这项任务？

我相信我可以在CryptoAPI中使用一些功能，但我真的不确定从哪里开始。我很感激你能提供的任何帮助。

4

2 回答 2

8

我将实现基于 MD5 的挑战响应身份验证。

来自维基百科 http://en.wikipedia.org/wiki/CRAM-MD5

协议

  1. Challenge：在 CRAM-MD5 认证中，服务器首先向客户端发送一个挑战字符串。
  2. 响应：客户端响应用户名，后跟一个空格字符，然后是一个 16 字节的十六进制摘要。摘要是 HMAC-MD5 的输出，其中用户的密码作为密钥，服务器的原始质询作为消息。
  3. 比较：服务器使用相同的方法来计算预期的响应。如果给定的响应和预期的响应匹配，则认证成功。

这提供了三种重要类型的安全性。

  1. 首先，其他人在不知道密码的情况下无法复制哈希。这提供了身份验证。
  2. 其次，其他人无法重放哈希——它依赖于不可预测的挑战。这被称为新鲜度或重放预防。
  3. 第三，观察者不学习密码。这称为保密。

该协议提供这三个安全优势的两个重要特性是单向哈希和新随机挑战。

此外，您可以在质询字符串中添加一些应用程序标识，以便对质询的发送者进行双重检查。

重要提示：它有一些弱点，请仔细评估它们对您的影响。

于 2010-11-22T19:06:56.570 回答
7

关于口头挑战/响应策略：十多年来，我们使用这种方法在全球 5000 台工作站上许可了一个小众应用程序。我们的支持团队将其称为“导弹发射代码”，因为它与老电影中的经典导弹发射验证过程相似。

这是保护程序的一种非常耗时的方法。它消耗了我们员工和客户大量阅读用户代码的时间。他们都讨厌它。

您的情况/背景可能会有所不同。也许您不会像我们那样频繁地使用它。但这里有一些建议：

  1. 仔细考虑代码的长度和内容：大多数用户（和支持人员）讨厌输入大量字符。许多用户是糟糕的打字员。考虑与添加的安全性数量相比，包含标点符号和区分大小写的长字符串是否会过度加重它们的负担。

  2. 在使用口头挑战/响应实施多年后，我们将其保留在原地（作为后备），但添加了一个简单的自动化系统。我们选择使用 FTP 而不是更复杂的 Web 方法，这样我们就不必在我们的内部服务器上运行任何软件（或与我们的 IT 人员打交道！）

基本上，我们使用 FTP 文件来进行之前在手机上进行的交换。服务器在 FTP 服务器上放置一个包含质询短语的文件。文件的名称是客户的名称。我们的支持人员有一个程序可以在我们的 ftp 站点上自动创建此文件。

我们的工作人员指示客户点击读取 FTP 文件、对其进行身份验证并将响应文件放回服务器的热键。

我们的支持人员的软件一直在轮询等待客户的软件创建响应文件。当它看到该文件时，它会下载它并确认其内容，然后将其从服务器中删除。

当然，您可以在给定会话中根据需要在任一方向上多次进行这种交换，以实现您的目标。

文件中的数据可以具有与您口头使用的相同的 MD5 密钥，因此它是您想要的安全性。

该系统的一个弱点是用户必须具有 FTP 访问权限。我们发现我们的大多数用户（所有企业）都可以访问 FTP。（当然，您的客户群可能不会......）如果我们在现场的应用程序无法访问我们的FTP站点，它会明确说明问题，以便我们的客户可以向他们的IT人员请求他们打开访问权限。同时，我们只是回到口头代码。

我们毫无问题地使用了普通的 Indy FTP 工具。

毫无疑问，这种方法存在一些弱点（可能包括我们没有想到的一些弱点。）但是，对于我们的需要，它已经很棒了。我们的支持人员和客户都喜欢它。

抱歉，如果这些都与您无关。希望这对您有所帮助。

于 2010-11-22T20:26:10.687 回答