API身份验证设计和可攻击性

Question

问题:这种API身份验证技术是否易于破解？

apiKey = "123456789"
apiCallId = "1256341451"
apiSecret = "67d48e91ab2b7471d4be2a8c2e007d13"
sig = md5(apiKey + apiCallId + apiSecret) = 09c297a354219f173bfc49c2e203ce03

哪里

• apiKey:用户的一些唯一标识符
• apiCallId:一个必须增加值的唯一整数(例如UNIX时间戳)
• apiSecret:仅对用户和我们知道的字符串 - 不在URL中传递
• sig:此API调用的"unhackable"签名 - MD5哈希

示例API调用:

http://api.domain.com/?apiKey=123456789&apiCallId=1256341451&sig=09c297a354219f173bfc49c2e203ce03&param1=x&param2=y

此API不需要会话,也不是为第三方代表用户设计的.相反,它将由用户自己使用.

我真的很喜欢这个的简单性.要求apiCallId独特,并且不断增加意味着重用a sig是不可能的,所以我觉得它是安全的(防止重放攻击),但我不是专家.

其他API在计算时使用按字母顺序排序的所有GET参数sig,但我不明白为什么在包含时需要这样做apiCallId.

请在实施和发布之前尝试破解它.

我欢迎任何反馈,建议和安全教育.

Answer 1

除了不检查参数(这将是一个非常大的问题)之外,你正在做的事情看起来相当合理.

与您的设计非常相似的东西,可能是明智的复制是亚马逊网络服务请求认证方案

特别要确保参数的编码方案明确且可逆; 亚马逊一度搞砸了这一点.从错误中吸取教训.:)

从密码学的角度来说,你所做的并不是一种签名,而是一种消息认证码(MAC).可以由共享密钥的任何人创建和验证MAC(术语"签名"通常保留用于诸如DSA或RSA的公钥方案).MD5(msg || K)是一个已知且合理的MAC; 我不确定你是偶然还是故意错过了它,但是表面看起来相当的方法MD5(K || msg)是非常不安全的,因为MD5(以及大多数其他哈希)的怪癖函数)设计意味着如果你知道H(m)你可以很容易地计算出任何m2的H(m || m2) - 所以如果你使用的是MD5(K || param1 = 5),有人可以把它从电线上拔掉然后创建MD5(K || param1 = 5,param2 = 666).(它可能比你感兴趣的技术要强一些,但这被称为长度扩展属性).

然而,虽然MD5(K || msg)可能"很好",但你最好使用类似HMAC的东西,因为它实际上是设计为MAC.MD5有很多问题,但没有直接影响它作为MAC的使用(但是 - MD4已经以这种方式被破坏).因此,为了面向未来(以及审核),请使用HMAC和SHA-1或SHA-256.即使您不想引入加密库,HMAC也非常简单,并且SHA-1和SHA-2有已知值,因此您可以检查代码.