类似SecurID的web服务身份验证

本文关键字：服务 身份验证 web SecurID 类似 | 更新日期: 2023-09-27 18:29:37

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

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

然而，我遇到了一件我不知道该怎么处理的事情。如果它每60秒更改一次，客户端在第59秒生成密钥，然后服务器响应请求所需的时间超过1秒，则它的密钥不会有什么不同，请求将被拒绝。

有什么好办法处理这个案子吗。。。也许钥匙每60秒就换一次，但换了几秒钟后就好了吗？

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

想法？

类似SecurID的web服务身份验证

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

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

我还要补充第三项安全措施。。。IP筛选。如果这是一个API，我认为它应该有一些共享的"秘密"密钥，限制谁可以访问它。这将防止你的密钥被公开，并防止有人试图恶意攻击你的网站，如果他们碰巧破解/获取了他们的密钥。

您所描述的（RSA的SecureID）基于TOTP算法。

你所描述的时间问题不仅是一个问题，而且你还应该记住，并非所有的时钟都以相同的速度运行。客户端的时钟可能比服务器的时钟运行得稍快或稍慢，随着时间的推移，它们可能会失去几分钟的同步。TOTP算法处理这一问题的方式（见RFC的第6节）是让服务器不仅根据当前时间代码，还根据未来的几个代码和过去的几个代码来验证它从客户端接收的代码。

                            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#实现，其中一个声称可以使用Google验证器（我知道它符合TOTP RFC）。

注意：大多数TOTP库不为您处理重新同步过程，因为您需要存储同步偏移量。不过，这对于您自己的构建来说相当简单，只需阅读RFC的相关章节，就可以彻底理解这个过程。

p.S.

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

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

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

相关文章：