使用移动应用程序进行API身份验证（通过SMS）

Question

我们目前的任务是使用RESTful API实现移动应用程序通信（最好是简单的）身份验证系统。后端具有用户特定的数据，由用户的电话号码标识。我试图更多地了解安全性，不同的方法以及他们为什么以他们的工作方式工作。

我认为一个简单的认证系统的：

• 客户端发送的验证请求，以包括他们的电话号码和一个生成的GUID的API。
• 服务器使用验证码向手机号码发送短信。
• 客户端通过发送其唯一的GUID，电话号码和验证码来验证他们的设备。
• 服务器响应某种访问令牌，客户端可以使用该令牌来进一步请求。

我有以下问题：

是否有这种做法的任何重大缺陷？ 假设我们使用HTTPS，它是否足够安全地发送数据，否则未加密？ 可以将访问令牌安全地存储在移动设备上，以便只有我们的应用可以读取它们？ 还有什么我们没有想到的？

我们已经认识到，当手机被盗或被盗用时，数据不再安全，但这是一个难以克服的风险。访问令牌可以暂时有效，以最大限度地降低此风险。

我认为这种方法是简单的方法，有一个巨大的缺陷:)你能指导我吗？

Answer 1

有一个缺陷。该系统容易受到暴力攻击。

假设我是攻击者。我会为自己生成一个GUID，并随同一些任意的电话号码一起发送。

接下来，我将通过可能的短信代码强制我的方式 - 如果是6位数字，则只有10^6个组合。暴力行为只需几秒钟 - 然后我就可以获取有此电话的人的数据。

另外，正如Filou在评论中指出的那样，人们可以强迫您发送任意数量的短信，实际上使您免费承受经济损失。

还有从这次攻击中没有有效的防御：

1. 如果试图对一个给定的UID的数量有限（N），我会 重新生成GUID中的每N次尝试。
2. 如果每个电话的时间请求数量有限制，我可以通过用虚假请求淹没每个可能的号码来执行DoS/DDoS攻击 - 因此，任何人都无法执行任何请求。

SMS之前的登录名/密码或证书认证是强制性。另外：

1. 千万不要在加密/安全协议中使用像GUID之类的东西。 GUID是确定性的（即知道一个值，你可以预测未来的值）。使用加密库内置函数生成随机流
2. 永远不要试图自己设计安全协议。决不。即使SSL 1.0的创作者都陷入了困境 - 他们是尖锐的人，但是还是有很多警告。更好地复制通用和经过验证的方案（Google的身份验证就是一个很好的例子）。

Answer 2

您提到的方法将正常工作。客户端将用电话号码和随机ID发起请求，服务器向设备返回验证令牌。令牌一次只能在设置过期时使用。然后，客户端将发送电话号码，之前使用的随机令牌和服务器验证的验证令牌。如果有效，服务器将发送会话令牌（或授权令牌）或可用于认证的类似信息。会话令牌可以从服务器设置超时。
你没有提到它是否是一个网络应用程序。如果它是一个Web应用程序，则可以从服务器设置一个仅限https的会话Cookie。否则，您可以将其存储在本地应用程序的本地商店中。通常情况下，应用程序无法读取属于其他应用程序的私人数据。
所有通信都必须使用HTTPS进行。否则，整个方案可能会通过嗅探流量而受到威胁，因为最终您使用的是身份验证令牌。