验证没有电子邮件和密码。

Question

我正在尝试为apis设置身份验证系统。但与传统方式不同，这将是没有电子邮件和密码

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

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

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

服务器用户表将是这样的

id || mobile_number || device_id || gcm_id ||的auth_token

问题1：

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

问题2：

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

问题3：

此类身份验证存在哪些缺陷。我不希望用户键入电子邮件和密码，但同时想要识别用户的个性化计算。

Answer 1

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

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

对于您的客户机密和您的身份验证令牌，就像密码一样，您的目标应该是让它们长而随机。如果身份验证令牌是自动轮换的，那么您可以在不引入实际风险的情况下缩短它。我说至少16个随机字节，即使对于短命令牌也应该是最小的，因为12个字符在实际离线哈希暴力强制的范围内，并且在今天合理的范围内有一个相当大的安全窗口是好的以及明天在破解能力方面的改进。

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

Answer 2

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