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

Question

在过去的几周里，我开始构建REST-Producing / Consuming Web应用程序，因此开始担心我的通信安全性。

我制定了以下程序：

1. 一个REST-Consumer和一个REST-Producer秘密协商一个共同的秘密并用这个秘密初始化一次性密码（OTP）-Component。
2. 每次请求和响应时，客户端都会发送OTP。
   • 此OTP由OTP-Component根据协商的秘密生成。
   • 另一个合作伙伴生成相同的OTP顺序，并检查发送的OTP是否正确并接受或阻止通信。
3. OTP链空转后，两个通信器交换一个新秘密并重新初始化（1。）。

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

1. 计算OTP 足够快来处理客户端上的ms-transactions？
2. 与其他安全功能相比，OTP的开销相对较小？
3. OTP程序比TLS通信更安全吗？
4. OTP安全性是否可以作为一种使用 HTTP -channels的方法？ （假设，数据是可读的！）
5. 哪些安全实施与解释的程序一样安全，但更便宜，更快或更不容易出错？

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

Answer 1

好的，我已经更彻底地阅读了你的问题，现在就明白了。 ： - ）

1. 如果您要预先生成双方的OTP列表，那么应该 对性能没有问题。但是你需要保护 存储OTP，这对于谁有权访问可能很棘手 到系统。

2. 当您预先生成时，开销是恕我直言 列表

3. TLS是传输层安全，OTP应用层因此没有 直接可比性。 TLS＆lt; 1.2可能是不安全的，但OTP也是如此 生成它们的方法很薄弱。这让我想到了下一点：

4. 如果您发送未加密的OTP，则可能会执行此操作 中间人并重新设计算法并预测下一个算法 动态口令。

5. 在生产中已经使用过的方法不易出错 例如Jax-RS secured with CXF。便宜？可能是，取决于 关于OTP的实施（购买，制造等）更快？没有 在1和2的答案中说明：如果你有预先生成的OTP，那就没有太大的开销。

无论上述答案如何：在此领域实施自定义解决方案之前，您应该始终三思，因为错误至关重要。考虑一下您的沟通所面临的威胁，进行权衡分析并查看结果。也许你会满意使用TLS＆gt; 1.2