这个简单的REST身份验证方案安全吗？

Question

我一直在研究REST身份验证方案（许多在SO上讨论过），其中许多似乎对我的目的过于复杂。我已经从更复杂的元素中制定了一个更简单的方案：但我想知道我的方法中是否存在任何安全漏洞。

影响因素：

• TLS到处都太慢而且资源很重
• 我不要求安全防止窃听，因为所有信息都是公开的。

建议的认证方案：

• “注册”和“登录”是通过TLS连接实现的。在登录时，提供用户名和密码，服务器返回共享密钥（然后由客户端存储在本地存储中，例如HTML5本地存储，应用程序存储等）。
• 所有其他请求都通过明文HTTP
进行

客户端算法：

• 在发送之前，每个请求都使用共享密钥“加盐”，并且对盐渍请求进行SHA哈希。
• 此哈希在自定义HTTP标头中插入请求中。
• 从请求中删除了盐。
• 请求与自定义标头一起发送。

服务器端算法：

• 服务器从请求中隔离并删除自定义Hash标头。
• 服务器使用共享密钥对请求字符串进行限制。
• Server获取salted请求的哈希值，并将其与自定义哈希头的值进行比较。
• 如果它们相同，我们已经确定哪个用户发送了请求，并且可以根据这些知识继续授权等。

我忽略了这个方案中的任何漏洞吗？

Answer 1

我会在这里质疑你的假设。

TLS到处都太慢而且资源太重

对于API来说，TLS几乎无处不在，其中一个原因是因为现在客户端和服务器支持它都相对便宜。多少开销？像往常一样＆＃34;它取决于＆＃34;但对于大多数现代API，甚至像Facebook和Twitter这样的大众消费者API来说，它们都可以忽略不计，只能转向使用它。

我不需要安全防范窃听，因为所有信息都是公开的。

这是关于TLS的常见神话。即使是公共数据，也要考虑其含义：

• 任何中间代理都可以注入自己的请求和响应。它可能是垃圾，恶意，微妙的错误，无论如何。安全通信不仅仅是为了保持内容的私密性，还要保持其完整性。 （一个常见的例子是电信公司和酒店向网站注入广告。）
• 数据可能是公开的，但流量可能仍然是敏感的。如果您能监控Apple的维基百科请求怎么办？如果对汽车相关文章的要求出现飙升，会不会有意思？如果没有TLS，中介可以监控用户的请求。

没有一个批评你的算法。您可以在密码学堆栈上询问，但它被认为是推出自己的身份验证的风险很大，现在很少值得。

Answer 2

您所描述的是基于MAC的身份验证方案。您应该查看Hawk或AWS身份验证方案，而不是滚动自己的实现。

这种认证方案的缺点是需要验证请求的服务器需要与认证服务器通信才能获得密钥。这会以负面的方式影响系统的可扩展性。

基于令牌的身份验证方案可以验证请求，而不会因数字签名而返回令牌颁发机构。

最后，我同意@mahemoff认为TLS正在变得无处不在，very cheap。实际上，视情况而定HTTPS may outperform HTTP。