类似 SecurID 的 Web 服务身份验证答案

【问题标题】：SecurID-like web-service authentication类似 SecurID 的 Web 服务身份验证
【发布时间】：2013-08-30 19:59:12
【问题描述】：

我正在开发一个非常小的 ASP.NET ASHX Web 服务，该服务在 Azure 上运行，我希望确保安全。它必须能够在没有用户交互的情况下工作，所以我想只是将一些加密的密钥传递给请求。但后来我想，以防万一，我可能应该不断地改变那个键。

到目前为止，我的想法是每 60 秒在客户端和服务器上以相同的方式生成一个密钥，对其进行哈希处理，并将其用作密钥。

但是，我遇到了一些我不确定如何处理的事情。如果它每 60 秒更改一次，并且客户端在第 59 秒生成密钥，然后服务器响应请求的时间超过 1 秒，则它的密钥不会有所不同，并且请求将被拒绝。

有什么好的方法来处理这种情况...也许密钥每 60 秒更改一次，但在更改后的几秒钟内是好的？

我意识到可能还有其他方法可以保护服务，但出于一些原因，我已经排除了客户端证书之类的东西，而且总的来说，我可以接受它非常简单。我只是希望它比不变的密码更简单。

想法？

【问题讨论】：

我认为我的旧 RSA 令牌发生这种情况时，它只会请求下一个密钥作为验证。
为什么在服务调用 10 次后不更改密钥？！

标签： c# asp.net authentication one-time-password

【解决方案1】：

您显然是在使用 HTTPs 保护服务，这将是第 1 步。

您希望密钥过期的身份/身份验证，因为您提到之前的密钥在短时间内有效。服务器将针对这两个密钥中的任何一个进行身份验证。

我还会添加第三个安全措施...IP 过滤。如果这是一个 API，我认为它应该有一些共享的“秘密”密钥，限制谁可以访问它。这将防止您的密钥泄露出去，防止有人试图恶意攻击您的网站（如果他们碰巧破解/获取了他们的密钥）。

【讨论】：

是的...忘了提，但是是的，HTTPS。凉爽的。一切听起来都不错。谢谢！

【解决方案2】：

您所描述的内容（RSA 的 SecureID）基于 TOTP algorithm。

您描述的不仅是时序问题，而且您还应该记住，并非所有时钟都以相同的速度运行。客户端的时钟可能比您的服务器时钟运行得稍快或稍慢，并且随着时间的推移，它们可能会变得不同步几分钟。 TOTP 算法处理此问题 (see section 6 of the RFC) 的方式是让服务器验证它从客户端接收的代码，不仅针对当前时间代码，还针对未来的几个代码和过去的几个代码。

                            Client       Server
                    Time    Code         Code   Time    Offset
                                   Match 849207 8:30:00 -0:00
                                         641239 8:30:30 -0:00
                                         761548 8:31:00 -0:00
Current client time 8:30:00 849207       103970 8:31:30 -0:00 Current server time
                                         846541 8:32:00 -0:00
                                         861321 8:32:30 -0:00
                                         132465 8:33:00 -0:00

如果服务器检测到代码不同步一定量，它会计算偏移量（时钟不同步的时间），然后在将来考虑该偏移量。

                            Client       Server
                    Time    Code         Code   Time    Offset
                                         628484 8:45:00 -1:30
                                         137864 8:45:30 -1:30
                                         679913 8:46:00 -1:30
Current client time 8:45:00 264951 Match 264951 8:46:30 -1:30 Current server time
                                         971034 8:47:00 -1:30
                                         626378 8:47:30 -1:30
                                         599171 8:48:00 -1:30

即使时钟继续偏离，当代码变得太不同步时，服务器也会通过增加偏移量来重新同步。

如果您继续这样做，我强烈建议您使用符合 RFC 的库。大多数语言都有相对容易找到的开源实现，这将使您的消费者更容易集成此身份验证。有几个 C# 实现，this one 声称可以使用 Google 身份验证器（我知道它符合 TOTP RFC）。

注意：大多数 TOTP 库不会为您处理重新同步过程，因为您需要存储同步偏移量。不过，这很容易自行构建，只需通读 RFC 的相关部分，以便彻底了解该过程。

附言

如果您打算将其用于机器对机器的身份验证，我建议您考虑一下它是否真的值得。虽然它很容易实现，但它仍然比直接的用户名和密码要多得多，而且它可能不会增加太多（如果有的话）真正的安全性（如果你没有使用 SSL，那么我会说不然。 )

类似 TOTP 的系统在共享密钥 (code=TOTP(key, time)) 上运行。这对人类很有用，因为攻击者无法在没有物理访问 SecureID（或任何品牌）令牌的情况下窃取代码或共享机密。唯一的攻击是从用户那里获取当前代码并立即使用它。但是，对于机器对机器的身份验证而言，情况并非如此，因为客户端机器必须有权访问共享密钥才能生成代码。如果管理员或攻击者可以从客户端系统窃取静态密码，那么他们没有理由不能窃取共享密钥。

我认为，在大多数情况下，类似 TOTP 的身份验证为机器-机器通信添加的唯一内容是一层模糊性。只是我的两分钱。

【讨论】：