我正在开发一个在Azure上运行的非常小的ASP.NET ASHX Web服务，我想保证安全。它必须能够在没有用户交互的情况下工作，所以我想只是将一些加密的密钥传递给请求。但后来我想，为了以防万一，我应该不断地做出关键改变。
到目前为止，我的想法是每隔60秒在客户端和服务器上以相同的方式生成密钥，哈希，并将其用作密钥。
然而，我遇到的事情我不知道如何处理。如果它每60秒更改一次，并且客户端在第二个59上生成密钥，然后服务器响应请求需要更长的时间，然后1秒钟，它的密钥将不会有所不同，请求将被拒绝。
有没有什么好方法可以处理这种情况...也许钥匙每隔60秒就会改变一次，但是在改变之后的几秒内它会变好吗？
我意识到可能有其他方法来保护服务，但我已经排除了客户端证书之类的东西，原因有几个，而且一般来说，我很好，因为它很简单。我只是希望它比不变的密码简单。
思想？
答案 0 :(得分：0)
您显然使用HTTP来保护服务，这将是第1步。
您希望密钥过期的身份/身份验证，因为您提到前一个密钥在短时间内有效。服务器将对两个密钥中的任何一个进行身份验证。
我还要添加第三个安全措施...... IP过滤。如果这是一个API，我认为它应该有一些共享的“秘密”密钥，它应该限制谁可以访问它。这会阻止您的密钥进入公开状态，并且如果他们碰巧破解/获取密钥，则会有人试图恶意攻击您的网站。
答案 1 :(得分：0)
您所描述的内容（RSA的SecureID）基于TOTP algorithm。
您不仅要描述问题的时间问题，还要记住并非所有时钟都以相同的速度运行。客户端的时钟可能比服务器时钟稍微更快或更慢，并且随着时间的推移，它们可能会在几分钟内失去同步。 TOTP算法处理此问题的方式（see section 6 of the RFC）是让服务器验证它从客户端接收的代码，而不仅仅是当前的时间代码，还有将来的几个代码以及过去的几个代码。 / p>
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的相关部分，以便您彻底了解该过程。
P.S。
如果您计划将此用于机器到机器的身份验证，我建议您考虑它是否真的值得。虽然它实现起来相当容易，但它仍然比直接的用户名和密码要多得多，并且它可能不会增加太多（如果有的话）真正的安全性（如果你没有使用SSL，那么我会说不然。 ）
类似TOTP的系统在共享密钥（code=TOTP(key, time)）上运行。这对人类非常有用，因为攻击者无法在不对SecureID（或任何品牌）令牌进行物理访问的情况下窃取代码或共享密钥。唯一的攻击是从用户那里获取当前代码并立即使用它。但是，对于机器到机器的身份验证，情况并非如此，因为客户端计算机必须能够访问共享密钥才能生成代码。如果管理员或攻击者可以从客户端系统中窃取静态密码，则他们没有理由不能窃取共享密码。
我认为，在大多数情况下，类似TOTP的身份验证增加机器通信的唯一因素是一层默默无闻。只是我的两分钱。