API 身份验证设计和可破解性 [英] API authentication design and hackability

问题描述

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

Question: Is this API authentication technique easily hackable?

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

哪里

• apiKey:用户的唯一标识符
• apiCallId:一个唯一的整数，其值必须增加(例如 UNIX 时间戳)
• apiSecret:只有用户和我们知道的字符串 - 不传入 URL
• sig:此 API 调用的不可破解"签名 - MD5 哈希

• apiKey: some unique identifier for the user
• apiCallId: a unique integer that must be increasing in value (e.g. UNIX time stamp)
• apiSecret: string known only to the user, and us - not passed in URL
• sig: "unhackable" signature of this API call - MD5 hash

示例 API 调用:

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

此 API 不需要会话，也不是为第 3 方代表用户使用而设计的.而是由用户自己使用.

This API does not require a session, and is not designed for a 3rd party to use on behalf of a user. Instead, it is to be used by the user themselves.

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

I really like the simplicity of this. The requirement of apiCallId being unique, and always increasing means reusing a sig is not possible, so I feel like it is secure (protected against replay attacks), but I am not an expert.

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

Other APIs use all of the GET parameters sorted alphabetically when calculating the sig, but I do not see why this is necessary when including apiCallId.

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

Please try and hack this now before it is implemented and released.

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

I welcome any feedback, suggestions and security education.

推荐答案

除了不检查参数(这将是一个相当大的问题)外，您所做的似乎相当合理.

What you are doing seems reasonably sane, except for not checking the parameters (which is going to be a pretty big problem).

与您的设计非常相似的东西是 亚马逊网络服务请求认证方案

Something which is very similar to your design which it might be wise to copy is the Amazon Web Services Request Authentication Scheme

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

In particular make sure your encoding scheme for the parameters is unambiguous and invertible; Amazon screwed this up at one point. Learn from their mistakes. :)

从密码学的角度来说，您所做的不称为签名，而是称为消息验证码 (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).(这可能比您感兴趣的技术性更强，但这称为 长度扩展属性).

Cryptographically speaking, what you are doing is not called a signature but rather a message authentication code (MAC). A MAC can be created and verified by anyone who shares the secret key (the term 'signature' is normally reserved for public key schemes like DSA or RSA). MD5(msg || K) is a known and reasonably sane MAC; I'm not sure if you missed it by accident or on purpose, but a method that seems on the surface to be equivalent, MD5(K || msg), is quite insecure, because a quirk in how MD5 (and most other hash functions) are designed means that if you know H(m) you can easily compute H(m || m2) for any m2 - so if you were using MD5(K || param1=5), someone could pull this off the wire and then create MD5(K || param1=5,param2=666). (It's perhaps a bit more technical than you're interested in, but this is called the length extension property).

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

However while MD5(K || msg) is probably 'fine', you are better off using something like HMAC, because it was actually designed as a MAC. MD5 has a lot of problems but nothing directly affecting its use as a MAC (yet - MD4 has been broken in this way). So for future-proofing (and audit-proofing) use HMAC with SHA-1 or SHA-256 instead. Even if you don't want to pull in a crypto library, HMAC is quite simple and there are known values available for SHA-1 and SHA-2 so you can check your code.

这篇关于API 身份验证设计和可破解性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！