无需电子邮件和密码的身份验证。

Question

我正在尝试为 api 建立一个身份验证系统。但与传统方式不同的是，这将无需电子邮件和密码

前端是一个安卓应用。最初应用程序在本地存储中将有空的 auth_token，现在应用程序请求 通过发送 mobile_number、device_id 和 gcm_id 来自服务器的身份验证令牌。

现在服务器生成一个16 securerandom hex, 并将其作为身份验证令牌发送到前端。

现在前端必须使用此身份验证令牌调用所有 API。

服务器用户表会是这样的

标识 ||手机号码 ||设备ID || gcm_id || auth_token

问题 1：

我应该根据 mobile_number、设备 ID 生成我的身份验证令牌还是可以独立生成？

问题 2：

应该更改身份验证令牌吗？或者我可以为用户永久使用相同的身份验证令牌。如果必须更改..请您指导我指出使用哪种策略

问题 3：

这种身份验证的缺陷是什么。我不希望用户键入电子邮件和密码，但同时希望识别用户以进行个性化计算。

Answer 1

身份验证令牌是密码。它们通常应设计为由客户端和服务器定期轮换自动处理，以减轻潜在的暴力攻击或凭据泄漏的风险，例如通过受损的用户设备或其他服务器漏洞（如 Heartbleed）。让您的令牌每隔一段时间（可能是 2 周或一个月）过期一次，并让客户端应用在令牌过期时要求重新验证，或者在令牌过期之前自动发出刷新令牌的请求。

您描述的用户身份验证方案适用于设备，而不是用户。您将无法使用这些详细信息可靠地识别一个用户和另一个用户，但这并不是说电子邮件+密码更好，它只是带有不同的使用期望。您通过其 device_id 识别移动设备，并通过验证电话号码增加其所有者未更改的信心。我不熟悉 GCM，所以我不确定添加了什么属性。要添加另一个对另一方来说不太容易进行欺骗的设备身份验证因素，我建议让您的客户端应用程序生成自己的“您知道的”密码以用于请求初始令牌。该设备内部密码可以作为其通过服务进行身份验证以自动颁发令牌的秘密，并且可以比常规的按请求身份验证令牌更不频繁地轮换。

对于您的客户端密码和您的身份验证令牌，就像密码一样，您应该致力于使它们长且随机。如果 auth 令牌是自动轮换的，您可以在一定程度上允许它更短而不会引入实际风险。我会说至少 16 个随机字节，即使是短暂的令牌也应该是最少的，因为 12 个字符在实际离线哈希暴力破解的范围内，并且在今天合理的情况之间有一个相当大的安全窗口是件好事以及明天在破解能力方面的改进。

请务必记住，您所描述的内容不会对个人进行身份验证，而只是对单个设备进行身份验证。听起来这就是您打算为您的项目做的事情，但了解区别及其含义很重要。

Answer 2

问题 3：一个陷阱是没有对您存储的密钥进行加密。如果将其存储在数据库（例如用户表）中，则应使用如下方法进行加密：https://saasbook.blogspot.com/2016/08/encrypting-application-level-data-at.html