使用一次性密码保护 REST 应用程序是个好主意吗？答案

【问题标题】：Is it a good idea to use One-time-passwords for securing REST-Applications?使用一次性密码保护 REST 应用程序是个好主意吗？
【发布时间】：2016-02-10 08:43:28
【问题描述】：

在过去的几周里，我开始构建 REST 生产/消费网络应用程序，因此开始担心我的通信安全。

我制定了以下程序：

一个 REST-Consumer 和一个 REST-Producer 秘密协商一个公共机密，并使用该机密初始化一个一次性密码 (OTP)-组件。
对于每个请求和响应，客户端都会发送一个 OTP。
- 此 OTP 由 OTP 组件根据协商的秘密生成。
- 另一个合作伙伴生成相同顺序的 OTP，并检查发送的 OTP 是否正确并接受或阻止通信。
OTP 链变空后，两个通信器交换一个新密钥并重新初始化 (1.)。

这种结构通常对多客户端环境和与许多 REST-Communicator 的通信有效。我对这个程序有几个问题：

OTP 的计算是否足够快以处理客户端上的 ms 事务？
与其他安全功能相比，OTP 的开销相对较小吗？
OTP 过程是否比 TLS 通信更安全？
OTP 安全性能否成为通过 HTTP 通道使用的方法？（假设数据是可读的就可以了！）
哪些安全实施与所述过程一样安全，但更便宜、更快或更不容易出错？

提前致谢。如果问题有任何错误或超出范围，请纠正我！

【问题讨论】：

我是否正确理解您希望为每个请求生成 OTP，这意味着（因为您不知道发送请求的时间）您必须至少每秒计算一次 OTP .可能是延迟问题。比较 OTP 和 TLS 就像比较苹果和橘子。 ;-)
我可以想象按需或在每个时间单位频繁生成 OTP。对于 TLS，我的意思是简单地使用 HTTPS 作为传输协议。

标签： rest security http ssl https

【解决方案1】：

好的，我已经更彻底地阅读了您的问题并理解了它。 :-)

如果您要预先生成双方的 OTP 列表，则应该在性能方面没有问题。但是，您需要确保存储 OTP，这对于谁有权访问可能很棘手到系统。
恕我直言，当您预生成列表。
TLS 是传输层安全，OTP 应用层所以没有直接可比性。 TLS
如果您发送未加密的 OTP，则可以执行中间人并重新设计算法并预测下一个一次性密码。
像已经在生产中使用的方法那样不易出错例如Jax-RS secured with CXF。更便宜？可能，取决于关于OTP（购买、制造等）的实施更快？没有。在对 1 和 2 的回答中陈述：如果您有预先生成的 OTP，那么开销并不大。

无论上述答案如何：在实施该领域的自定义解决方案之前，您都应该三思而后行，因为错误可能至关重要。考虑对您的沟通的威胁，进行权衡分析并查看结果。也许你会满意使用 TLS > 1.2？

【讨论】：