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

Question

我正在尝试使用apis的身份验证系统。但不像传统的方式，这将是没有电子邮件和密码

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

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

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

服务器用户表会是这样

ID || mobile_number || device_id || gcm_id || AUTH_TOKEN

问题1：

我应该产生我的身份验证令牌基础上，MOBILE_NUMBER，设备ID还是可以独立生成？

问题2：

如果该身份验证令牌是否会改变？或者我可以为用户永久使用相同的身份验证令牌。如果要改变..可以请你指导我指出要使用的策略

问题3：

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

Answer 1

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

Answer 2

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

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

对于您的客户端机密和您的身份验证令牌，就像密码一样，您应该让它们变得漫长而随意。如果认证令牌是自动旋转的，那么在一定程度上可以让它短得多而不会带来实际的风险。我会说至少16个随机字节，即使是一个短暂的令牌应该是最小的，因为12个字符是在实际的离线哈希蛮力的范围内，并且在今天可能的事情之间有一个相当大的安全窗口是很好的以及明天的破解能力的提高。

重要的是要记住，你描述的内容不会验证一个人，而只是一个单独的设备。这听起来就是你打算为你的项目做的事，但了解这个区别以及它的含义是很重要的。