API认证的设计和可编程性 [英] API authentication design and hackability

问题描述

问：这是API认证技术很容易破解的。

？

  apiKey =123456789
apiCallId =1256341451
apiSecret =67d48e91ab2b7471d4be2a8c2e007d13
SIG = MD5（apiKey + apiCallId + apiSecret）= 09c297a354219f173bfc49c2e203ce03
 

其中，

• apiKey ：对于用户的一些唯一标识符


• apiCallId ：一个唯一的整数必须在值增加（例如UNIX时间戳）


• apiSecret ：字符串只知道用户和美国 - 在URL没有通过


• SIG ：此API调用的牢不可破的签名 - MD5哈希值

API呼叫范例：

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

此API不需要会话，不用于第三方代表用户的使用。相反，它是由用户自己来使用。

我真的很喜欢这个简单。的要求 apiCallId 是唯一的，始终不断增加手段重用 SIG 是不可能的，所以我觉得它是保护（针对重放攻击保护），但我不是专家。

其他API使用所有计算时按字母顺序排列的GET参数 SIG ，但我不明白为什么包括什么时候，这是必要的 apiCallId 。

请尝试，它的实施和发布之前，现在这个破解

我欢迎任何意见，建议和安全教育。

解决方案

你在做什么，似乎都是合理的，但不检查参数（这将是一个pretty大问题）。

东西是非常相似的设计，它可能是明智的复制是亚马逊Web服务请求验证方案

在特别请确保该参数的编码方案是明确的和可逆的;在一个点上亚马逊搞砸这件事。从错误中吸取教训。 ：）

密码学来说，你在做什么不叫签名，而是一个消息验证code（MAC）。一个MAC可以创建和任何人谁共享密钥验证（以下简称签名这一术语通常保留给像DSA或RSA公钥方案）。 MD5（MSG || K）是已知的，合理健全的MAC;我不知道如果因意外或故意错过了，但在表面上似乎是一个方法是等效的，MD5（K ||味精），是非常不安全的，因为在MD5（以及大多数其他散列的怪癖功能）设计意味着，如果你知道H（M），你可以很容易地计算^ h（M ||平方米）任何m2的 - 所以，如果你使用MD5（K ||参数1 = 5），有人可以把这事办成线然后创建MD5（K ||参数1 = 5，参数2 = 666）。 （这或许有点更多的技术比你有兴趣，但是这就是所谓的的长度扩展属性）。

然而，同时MD5（K ||味精）可能是精，你最好使用像HMAC，因为它实际上是设计成一个MAC。 MD5有很多问题，但没有直接影响其作为一个MAC使用（尚未 - MD4已经以这种方式打破）。因此，对于未来的打样（和审核校对）使用HMAC使用SHA-1或SHA-256来代替。即使你不想在加密库拉，HMAC是相当简单的并有可用于的 SHA-1 和 SHA-2 所以你可以检查你的code。

Question: Is this API authentication technique easily hackable?

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

where

• 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

Example API call:

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

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.

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.

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

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

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屋！