我觉得将来自移动/ Web应用程序的每个https请求中的用户名和密码发送给后端api是一个坏主意，但是我不能为为什么提供太多好的论据。
在服务器中，我们将密码的哈希存储在用户记录中。无论如何，对于每个请求，我们都需要从数据库中加载该用户记录，例如，检查用户是否仅被列入黑名单。由于我们需要在每个请求上加载用户记录，因此比较密码无需花费任何成本，因此无需管理另一个SessionID或令牌数据库。
另外，由于密码是通过https连接发送的，因此中间的人无法捕捉到它们。即使中间有人可以做到这一点，当用户需要首次登录时，他也可能也可以这样做（因为无论如何，他都需要在开始时发送密码）
那么，做什么的好方法呢？
这将是一个很大的安全性采访问题，因为它很好地衡量了安全领域的理解水平。
建议不要在每个请求中发送用户名/密码，但其他答案甚至都无法说明真正的原因。
从技术上讲，用户名/密码与API密钥之类的东西几乎相同，它们在有效期内是等效的。从某种意义上说，API密钥甚至更糟，因为根据实现的不同，通常将API密钥以纯文本形式存储在数据库中，而不是适当地散列密码（旁注，但是在散列时请使用bcrypt或pbkdf2之类的东西）。完全正确，每个请求都可以使用与API密钥相同的方式发送密码，也可以以相同的方式撤销密码，依此类推。等等。API密钥就是密码。在这方面绝对没有区别。
但是，至少由于以下原因，您在大多数情况下仍可能不应该这样做。
如果用户选择密码，则密码很弱。如果您有许多用户，则许多用户将具有123456之类的密码。容易猜出其中一些。您无需在API应用程序中运行此风险，但是，在下一个请求中，在每个请求中发送该风险或仅勉强修改此风险都可以，但这确实有点。
有时SSL / TLS中存在弱点。确实确实会不时地披露针对TLS的新攻击，然后最终对其进行修补。但是，在一段时间内，攻击者可能会从加密流中推断出比特，如果部分了解加密内容（即通用密码），则可能会变得更加容易。机会不是很高，但是问题是，对于许多TLS密码套件，攻击者现在可以记录流量，并在以后进行解密（因为它花费的时间很长，或者该方法尚未发明）。如果他只解密已经使用3年的API密钥，那很好，但是如果它是用户密码...不太好。
服务器漏洞也可能是一个问题。不久前，openssl实施中存在一个漏洞，您实际上可以读取服务器内存的一部分（Web服务器进程）。如果网络服务器一直都收到用户密码，则它可能会多次出现在内存中。如果这只是一个临时API密钥（或会话ID或其他内容），那么对于攻击者来说价值不大。它仍然很好，但至少不是密码。
内部攻击者也是要考虑的事情。如果服务器上已经有攻击者，则攻击者可能无法访问数据库以直接读取/修改凭据，但可以在有限的时间内观察Web服务器进程。与上述相同，如果他只能观察临时ID而不是实际密码，那就更好了。
如果要随每个请求发送密码，则需要将密码存储在客户端上。在客户端上存储敏感内容通常不是一个好主意，这为攻击者提供了可能性。通常最好的做法是，用户输入凭据，接收一个临时令牌，然后客户端忘记实际的密码，直到令牌过期，并且用户必须再次提供密码。从用户体验的角度来看，这当然可以接受也可以不接受-但是安全性始终是一个平衡。:)
因此，您可以看到，在每个请求中发送用户名/密码不是直接的漏洞。实际上，它在许多情况下甚至可以接受。但是您可以使用临时凭证来使其更安全，如果成本合理，为什么不这样做呢？
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句