使用散列签名保护REST API

时间:2012-11-15 18:11:15

标签: web-services security hash

我在这里问了一个与此相关的问题:

Securely Passing UserID from ASP.Net to Javascript

但是现在我有一个更详细/具体的问题。我有服务,我有应用程序将使用我的计划来保护它,是基于某些值,随机数和密钥生成哈希。我唯一的问题是,似乎为了验证哈希,我必须发送所有值加上nonce,除了密钥。这是我设计中的一个缺陷还是这样的事情是如何完成的?我已经搜索过,并且无法确定这是否是正确的安全方式。

例如,假设我需要将值1,2和3传递给我的休息服务,所以我用户的电话号码,随机数和生成哈希的密钥,现在为了再次生成哈希我需要传递以上所有内容,除了密钥(我可以根据用户的电话号码检索)。

我完全离开了我的服务攻击,正确保护它,或介于两者之间?

编辑:进行拼写和语法修正

编辑2:最后通过使用MVC 4进行表单身份验证,两个项目之间相同的cookie名称以及使用全局应用的[Authorize]属性

来获得满意的解决方案

1 个答案:

答案 0 :(得分:1)

这个计划没有任何内在错误。如果客户发送:

data . nonce . hash(data . nonce . shared-secret)

然后服务器通过检查hash(data . nonce . shared-secret)是否与客户端提供的哈希匹配来验证消息,您可以安全地防止篡改和重放(当然,假设您使用的是合理的加密哈希算法) )。

在这种设计下,客户端甚至可以生成自己的nonce,前提是不存在两个客户端生成相同nonce的风险。

但是,窃听者仍然可以看到你发送的所有数据......所以,除非有充分的理由不这样做,否则我只会使用https(除非有其他要求我不知道,否则,完全足够了。