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调用的unhackable签名 - 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不需要会话，并且不是为第三方代表用户。相反，它是由用户自己使用。

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.

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

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).

与您的设计非常相似的东西，它可能是明智的，复制是 Amazon Web服务请求身份验证方案

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的m（m || m2） - 所以如果你使用MD5（K || param1 = 5），有人可以拉这个线然后创建MD5（K || param1 = 5，param2 = 666）。 （这可能比你感兴趣的技术更多，但这被称为 length extension property ）。

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已经以这种方式被破坏）。因此，为了防止未来（和审计）使用HMAC与SHA-1或SHA-256。即使你不想加入加密库，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屋！