API 身份验证设计和可破解性

Question

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

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

在哪里

apiKey :用户的一些唯一标识符

apiCallId :一个唯一的整数，它的值必须增加(例如 UNIX 时间戳)

apiSecret :只有用户和我们知道的字符串 - 未传入 URL

sig:此 API 调用的“不可破解”签名 - MD5 哈希值

示例 API 调用:

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

此 API 不需要 session ，也不是为第 3 方代表用户使用而设计的。相反，它由用户自己使用。

我真的很喜欢这种简单性。 apiCallId 的要求是唯一的，并且总是增加意味着重用 sig 是不可能的，所以我觉得它是安全的(防止重放攻击)，但我不是专家。

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

请在实现和发布之前尝试破解它。

我欢迎任何反馈、建议和安全教育。

Answer 1

除了不检查参数(这将是一个非常大的问题)之外，您正在做的事情似乎相当合理。

与您的设计非常相似的东西是Amazon Web Services Request Authentication Scheme 可能是明智的复制。

尤其要确保您的参数编码方案是明确且可逆的；亚马逊 screwed this up在一个点上。从他们的错误中吸取教训。 :)

从密码学上讲，您所做的不称为签名，而是称为消息验证码 (MAC)。任何共享 key 的人都可以创建和验证 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)。 (它可能比您感兴趣的技术性更强，但这称为 length extension property )。

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