假设我有三部智能手机发送带有UUID的信标：X。其中两个拥有名为True App的应用程序：第一个具有major：1，minor：1第二个有major：1，minor：2
[第三部智能手机有一个名为Beacon Simulator的应用程序，它可以克隆其他两个的信标。
[应该认出前两个是欺骗信标。
哪种方法是同时解决Android和iOS问题的最佳方法？
有三种避免信标欺骗的常用方法：
使用辅助传输的标识符
您可以使用较难复制的辅助已知标识符（例如，蓝牙MAC地址）来尝试验证信标标识符是否来自预期来源。 此技术很少能很好地起作用，但是，因为确定的黑客也可以使用适当的设备来欺骗MAC地址（或任何其他传输的字段）。在移动设备上将这种方法与MAC地址一起使用也非常受限制-iOS设备根本无法读取信标的MAC地址，并且Android和iOS发射器都定期将其BLE发射器随机化。
旋转标识符哈希
许多信标系统试图通过使用专用信标格式来避免欺骗，该信标格式使用基于安全密码哈希算法的旋转标识符。这方面的两个示例是Gimbal（专有）和Eddystone-EID（开源，但由Google有效运行）。在每种情况下，您都必须调用服务器以“解析”从信标传输中接收到的旋转哈希，并将其有效地转换为应用程序可以使用的静态标识符。[这种方法在许多用例中是相当安全的，但是存在主要缺点：（a）系统复杂且难以设置。 （b）需要网络连接来解析标识符。如果您失去连接或网络速度很慢，则您的应用将无法运行。 （c）这种方法将您锁定在特定的供应商（Gimbal或Google）上。 （d）仍然可以通过在一个位置记录信标传输并在第二个位置重新广播来击败该系统。
使用次要因素来验证信标检测
次要因素的一个示例是验证每个信标的已知位置。如果知道每个信标的纬度和经度，则在看到信标时，请比较测得的纬度和经度以查看其是否合理接近。这样可以防止欺骗，除非非常接近。另一个例子可能是时间。如果您知道两个不同的信标将相距一英里，但是您的手机会在几秒钟内检测到两个信标，那么您可以合理地确定这两个检测中的一个被欺骗并做出了适当的响应。有许多其他特定情况的可能性。 此方法通常在基本安全性和易于实现之间提供良好的权衡，只要您的用例允许，并且您的安全性要求不是极端的。