api - 安全 API 身份验证方法

Question

我们正在开发一个新项目，我们是两个主要开发人员，在如何使用 token 来保护服务器和客户端之间的通信方面遇到了十字路口:

第一个建议:

第一步)客户端请求一个主 token ，通过将用户名和密码以及current_time(这个变量将保存在服务器的数据库和客户端中)发送到api，服务器解释输入，并呈现一个散列的 token (例如:58f52c075aca5d3e07869598c4d66648)将其保存在数据库中并将其返回给客户端。

第二步)客户端现在保存主 token ，并使用主 token +身份验证请求中发送的 current_time 变量创建新的散列 token (让我们调用这个新 token ，main_token)服务器也这样做并使用创建相同的 token 相同的算法。

Step 3) 客户端每次查询服务端API，都会向服务端发送main_token，现在服务端比较里面生成的token，和客户端发送的main_token，如果匹配就说明用户是真实的

第二个建议:

第一步)客户端生成两个随 secret 钥($key1 = rand(10000,90000)；
$key2 = rand(10000,90000);) 在 API 上的每个请求上，客户端使用查询类型创建一个哈希，并使用复杂算法创建两个键，并将这两个键 + 哈希发送到服务器

第二步)服务端，使用客户端使用的相同算法，创建一个哈希，并与客户端发送的进行比较，如果匹配，则服务器继续处理查询

现在，问题是，哪一种是用于保护 api 请求的最合乎逻辑、最安全的方法

此致

Answer 1

这两种解决方案都对安全性没有任何好处。

第一个建议

一旦我有了 main_token，我就可以计算任何哈希(main_token + 时间戳)。访问 API 所需的只是 main_token，那么为什么要打扰时间戳业务呢？

第二个建议

如果您随每个请求和查询类型发送两个随机数，那么是什么阻止我这样做并使用您的 API？算法？密码算法的规则是，如果你自己动手，有人会破解它。第二条规则是默默无闻的安全不起作用。

如果您的身份验证过程比您的 api 更安全，您可以以不同的方式保护调用:

身份验证阶段 (SSL)

客户端发送用户/密码并获取一个“Secret_token”，它是一个随机字符串。

Secret_token 存储在客户端和服务器端。

Secret_token 永远不会再次通过网络传输。

API 请求阶段

客户端创建请求

客户端规范化请求

客户端使用 Secret_token

计算规范化请求的签名*

客户端将请求+签名发送到服务器

服务器规范化请求

服务器使用 Secret_token

计算规范化请求的签名

如果签名匹配，服务器继续请求

计算签名

首先，规范化请求。这可能意味着提取包括方法(post、get、action、timestamp)在内的重要参数并将它们按顺序排列。然后通过 HMAC 算法运行该字符串，该算法将 Secret_token 作为参数。

分析

Secret_token 仅在身份验证发生时通过网络传输一次。假设身份验证过程非常安全(因为在此过程中传输密码，这是一个安全的假设)。

注意:通过明文发送仍然不安全，请使用 SSL。

HMAC 是众所周知的解决方案。看:

http://rc3.org/2011/12/02/using-hmac-to-authenticate-web-service-requests/

亚马逊的大部分 api 都是 hmac 签名的:http://docs.aws.amazon.com/general/latest/gr/signature-version-2.html

http://tools.ietf.org/html/rfc2104

http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/