【问题标题】：Is this simple REST authentication scheme secure?这个简单的 REST 身份验证方案安全吗？
【发布时间】：2015-09-25 04:28:02
【问题描述】：
我一直在研究 REST 身份验证方案（很多都在 SO 上讨论过），其中许多对于我的目的来说似乎过于复杂。我从更复杂的元素中制定了一个更简单的方案：但我想知道我的方法中是否存在任何安全漏洞。
影响因素：
- 无处不在的 TLS 太慢且资源繁重
- 我确实不需要安全防范窃听，因为所有信息都是公开的。
提议的认证方案：
- “注册”和“登录”是通过 TLS 连接实现的。登录时，提供用户名和密码，服务器返回共享密钥（然后由客户端存储在本地存储中，例如 HTML5 本地存储、应用存储等）。
- 其他所有请求都通过明文 HTTP 进行
客户端算法：
- 在发送之前，每个请求都使用共享密钥“加盐”，并为加盐的请求获取 SHA 哈希。
- 此哈希值插入到自定义 HTTP 标头中的请求中。
- 从请求中删除盐。
- 请求使用自定义标头发送。
服务器端算法：
- 服务器从请求中隔离并删除自定义哈希标头。
- 服务器使用共享密钥对请求字符串进行加盐。
- 服务器获取加盐请求的哈希并将其与自定义哈希标头的值进行比较。
- 如果它们相同，我们已经确定了哪个用户发送了请求，并且可以根据这些知识继续进行授权等。
此方案中是否存在我忽略的漏洞？
【问题讨论】：
标签：
rest
security
authentication
hash
【解决方案1】：
我会在这里质疑你的假设。
无处不在的 TLS 太慢且资源繁重
TLS 在 API 中几乎无处不在，其中一个原因是因为现在客户端和服务器都支持它相对便宜。多少开销？像往常一样，“这取决于”，但对于大多数现代 API，甚至是 Facebook 和 Twitter 等大众消费 API，转向完全使用它来说，肯定是微不足道的。
我不需要防窃听的安全措施，因为所有信息都是公开的。
这是关于 TLS 的常见神话。即使对于公共数据，也要考虑其影响：
- 任何中间代理都可以注入自己的请求和响应。它可能是垃圾的、恶意的、微妙的不正确的，等等。安全通信不仅是为了保持内容的私密性，也是为了保持其完整性。 （一个常见的例子是电信公司和酒店向网站注入广告。）
- 数据可能是公开的，但流量可能仍然是敏感的。如果您可以监控 Apple 的 Wikipedia 请求会怎样？如果对汽车相关文章的请求激增，会不会很有趣？如果没有 TLS，中介可以监控用户发出的请求。
其中没有一个批评您的算法。您可以在 Cryptography Stack 上提问，但推出自己的身份验证被认为是相当冒险的，而且现在很少值得这样做。
【解决方案2】：
您所描述的是基于 MAC 的身份验证方案。您应该查看Hawk 或AWS 身份验证方案，而不是滚动您自己的实现。
这种身份验证方案的一个缺点是需要验证请求的服务器需要与身份验证服务器对话以获取密钥。这会对系统的可扩展性产生负面影响。
基于令牌的身份验证方案可以验证请求，而无需由于数字签名而返回令牌颁发机构。
最后，我同意@mahemoff 的观点，即 TLS 正变得无处不在，very cheap。实际上，视情况而定，HTTPS may outperform HTTP。