我已经对这个主题进行了详尽的研究并且陷入困境 - 希望从有帮助的人那里得到一些澄清。
背景:我将蓝牙转发器连接到锁上，这些锁可以在我的应用程序中通过付款打开。用户支付固定费用，锁打开，他们拿起他们的元素，然后门关闭并锁上。我正在努力防止非付费用户能够打开这些锁的欺骗攻击。
我目前的解决方案在理论上是这样的:每个转发器都被赋予一个随机的 32 位盐。应用程序连接后，身份验证请求将发送到转发器，转发器会创建一个随机挑战字符串 + 其唯一的盐。然后，转发器使用 SHA256 对字符串进行哈希迭代 10,000 次(以防止暴力破解)。同时，原始挑战字符串+盐被传输到应用程序，然后应用程序通过 SSL 将其发送到安全服务器，共享 secret 哈希 key 和转发器盐位于其中。该字符串使用 Sha256 进行哈希迭代 10,000 次，发送回应用程序，然后发送回转发器，转发器根据其计算的哈希值验证服务器哈希值。如果相等，则打开锁。
我的问题是:这安全吗？我是否忽略了一些明显的安全漏洞，无论是蛮力还是其他？我完全错了吗？任何帮助或建议将不胜感激
最佳答案
需要考虑的一件事:
如果您将盐和挑战字符串传输到应用程序，然后再传输到服务器，则生成正确答案所需的所有信息都可用。唯一的 secret 是您的哈希算法，但它现在处于堆栈溢出状态。
为了让试图破坏您的系统的人的生活更加困难，您不需要在通信中发送盐。相反，当您向系统添加新的转发器时，您会将转发器 ID 及其唯一盐添加到服务器可以访问的数据库中。您发送随机挑战和转发器 ID，而不是发送盐。然后服务器使用转发器 ID 查找盐。
这样盐就不会被传输并保持 secret (只要您的服务器没有受到损害)。
这有它自己的问题。盐可以从转发器进行逆向工程，就像您用来生成哈希的算法一样。不过，这确实让事情变得更加困难，特别是如果你混淆和保护转发器上的盐。
为了完整起见，值得一提的是您要确保在所有组件之间发送的流量都经过加密。在服务器和客户端应用程序之间，这意味着使用 TLS。我对蓝牙知之甚少，所以我不知道加密通信的标准方法是什么。为了进一步保护客户端和服务器之间通过 TLS 的通信，您可能需要实现一种 pinning 的形式。 .
关于security - 使用散列和盐通过 SSL 进行身份验证，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38732175/