基于 REST 的 API 的安全性

Question

我一直在研究保护 API 以在 android/iphone 应用程序或网站应用程序中使用的技术。
我找到了一种我喜欢的技术，但不确定它是否好或有什么问题（除了是一个非常漫长的过程）。

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

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

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

Answer 1

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

在您的示例中，您听起来像是要使用以下伪代码创建令牌：

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

您的方式还不错，但我会将您的方法与 Amazon 的 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有关）