9

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

我想到了一个简单的身份验证系统：

  • 客户端向 api 发送验证请求，其中包括他们的电话号码和生成的 guid。
  • 服务器向手机号码发送一条带有验证码的短信。
  • 客户通过发送他们唯一的 guid、电话号码和验证码来验证他们的设备。
  • 服务器以某种访问令牌进行响应，客户端可以将其用于进一步的请求。

我有以下问题：

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

我们已经想到，当手机被盗或以其他方式受到损害时，数据不再安全，但这是一个难以克服的风险。访问令牌可能暂时有效，以尽量减少这种风险。

我假设这种方法很简单，并且某处存在巨大缺陷:)你能启发我吗？

4

2 回答 2

6

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

假设我是攻击者。我将为自己生成一个 guid，并将其与一些任意电话号码一起发送。

接下来，我将暴力破解可能的 SMS 代码 - 如果它是 6 位数字，则只有 10^6 种组合。暴力破解将是几秒钟的事情 - 然后我将访问拥有此手机的人的数据。

此外，正如 Filou 在评论中指出的那样，可以强迫您向您发送任意数量的 SMS，从而有效地使您免费承受经济损失。

这种攻击也没有有效的防御措施：

  1. 如果给定 UID 的尝试次数有限 (N)，我将每 N 次尝试重新生成 guid。
  2. 如果每部电话在一段时间内有请求限制，我可以通过用虚假请求淹没每个可能的数字来执行 DoS/DDoS 攻击 - 因此，没有人能够执行任何请求。

在 SMS 之前必须进行登录名/密码或证书验证。还：

  1. 永远不要在密码学/安全协议中使用 GUID 之类的东西。GUID 是确定性的（即，知道一个值，您可以预测未来的值）。使用加密库内置函数生成随机流
  2. 永远不要尝试自己设计安全协议。绝不。甚至 SSL 1.0 的创建者也有很多警告——他们是敏锐的家伙，请注意。更好地复制常见和经过验证的方案（谷歌的 auth 就是一个很好的例子）。
于 2013-08-13T13:07:38.407 回答
0

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

于 2013-08-13T11:03:42.463 回答