1.我有自己的REST API（“后端”）1.我有自己的（第一方/受信任的应用程序）移动的应用程序（“前端”）1.我希望我的用户能够直接在移动的应用程序中通过表单登录（而不是通过浏览器等）在这种情况下，身份验证的当前技术水平如何？在调用REST API时，是否可以只散列用户凭据并将其放入头中？或者是否有更安全的方法？
qqrboqgw1#
是的，还有更安全的方法。一种机制称为challenge-response authentication，服务器向客户机发送质询（例如随机数）。客户端使用hash_function(random_number + password)进行响应。因此，客户端将随机数和密码连接起来，然后创建一个散列。服务器计算相同的值，因此服务器知道密码是否正确。即使有人记录了纯文本流，他也无法伪造密码或可用于登录的散列。我所解释的挑战-响应认证要求服务器以纯文本的形式存储密码。但是Wikipedia说有一种方法可以使它工作而不在服务器上以纯文本的形式存储密码。因为最好只在服务器数据库中存储加盐的密码散列，以防有人泄露数据库。下面是登录方法的列表，我想OAuth2是最先进的（因为我记得当你在Thunderbird中登录GMail帐户时，在URL中看到过oauth）：https://afterlogic.com/mailbee-net/docs/MailBee.AuthenticationMethods.html
hash_function(random_number + password)
OAuth2
oauth
1条答案
按热度按时间qqrboqgw1#
是的，还有更安全的方法。
一种机制称为challenge-response authentication，服务器向客户机发送质询（例如随机数）。客户端使用
hash_function(random_number + password)进行响应。因此，客户端将随机数和密码连接起来，然后创建一个散列。服务器计算相同的值，因此服务器知道密码是否正确。即使有人记录了纯文本流，他也无法伪造密码或可用于登录的散列。我所解释的挑战-响应认证要求服务器以纯文本的形式存储密码。但是Wikipedia说有一种方法可以使它工作而不在服务器上以纯文本的形式存储密码。因为最好只在服务器数据库中存储加盐的密码散列，以防有人泄露数据库。
下面是登录方法的列表，我想
OAuth2是最先进的（因为我记得当你在Thunderbird中登录GMail帐户时，在URL中看到过oauth）：https://afterlogic.com/mailbee-net/docs/MailBee.AuthenticationMethods.html