2

我一直在研究保护用于 android/iphone 应用程序或网站应用程序的 API 的技术。
我找到了一种我喜欢的技术，但不确定它是好还是坏（除了是一个非常长的过程）。

处理（最初是用户端）：
首先通过散列用户密码创建盐。
然后通过散列请求的 url（通过查询字符串在末尾附加用户名）和 salt 来创建签名。
最后，通过对用户名和签名进行哈希处理来创建令牌。
令牌在标头内传递给服务器（每次）。

第一个请求：
第一个请求必须针对验证端点，并包含 device_id 作为查询字符串。
在服务器上进行相同的处理（如上），如果令牌与用户发送的令牌匹配，则将 device_id 存储在数据库中并分配给该用户名以供将来参考（在请求的 url 中找到设备 ID）并用于随后验证用户名/设备。

所有后续请求：
对于每个请求，处理必须在用户端和服务器端进行，令牌每次都不同（随着请求的 url 更改）。
没有包含代码，因为它尚未编写。

4

1 回答 1

5

您的身份验证模型是共享秘密身份验证。在您的情况下，您的用户密码用作共享密钥。您需要确保您有一种安全的方式来提前获取用户和服务器的密码。为了签署请求，您创建一条包含所有请求标头和数据的消息。然后散列该请求。然后该哈希（令牌）将随请求一起传递。服务器将在服务器上执行相同的签名和散列过程，并确保令牌匹配。

在您的示例中，您的声音就像您想使用以下伪代码创建令牌：

Token = hmac-sha1( Hash(Pasword + Salt) + RequestUrl + UserName )

你的方法还不错，但我会将你的方法与亚马逊的 REST Auth 模型进行比较，并实现他们详细说明的更接近的版本。http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

他们的实现：

"Authorization: AWS " + AWSAccessKeyId + ":"  + base64(hmac-sha1(VERB + "\n" 
                                 + CONTENT-MD5 + "\n" 
                                 + CONTENT-TYPE + "\n" 
                                 + DATE + "\n" 
                                 + CanonicalizedAmzHeaders + "\n" 
                                 + CanonicalizedResource))

他们有充分的理由包含您遗漏的一些字段，包括但不限于：

  • 时间戳是为了防止重放攻击。
  • content-MD5 是为了防止人们篡改请求数据（与 POST 和 PUTS 相关）
于 2013-01-15T14:51:41.030 回答