api - 从移动/网络应用向后端api发送每个请求的用户名和密码是否是个坏主意

Question

我觉得将来自移动/Web应用程序的每个https请求中的用户名和密码发送给后端api是一个坏主意，但是我不能为为什么提供太多好的论据。

在服务器中，我们将密码的哈希存储在用户记录中。无论如何，对于每个请求，我们都需要从数据库中加载该用户记录，例如，检查用户是否仅被列入黑名单。由于我们需要在每个请求上加载用户记录，因此比较密码无需花费任何成本，因此无需管理另一个SessionID或 token 数据库。

另外，由于密码是通过https连接发送的，因此中间的人无法捕捉到它们。即使中间有人可以做到这一点，那么当用户需要首次登录时，他也可能也可以做到这一点(因为无论如何，他都需要在开始时发送密码)。

那么，做什么的好方法呢？

Answer 1

这将是一个很大的安全性面试问题，因为它很好地衡量了安全领域中的理解水平。

建议不要在每个请求中发送用户名/密码，但是其他答案甚至都没有涉及到真正的原因。

从技术上讲，用户名/密码的与apit之类的几乎相同，在有效期内它们是等效的。从某种意义上说，API key 甚至更糟，因为根据实现的不同，您通常会将API key 以明文形式存储在数据库中，而不是使用适当的哈希密码(附带说明，但哈希时请使用bcrypt或pbkdf2之类的东西)。完全正确，在每次请求时都可以使用与API key 相同的方式发送密码，也可以以相同的方式撤消密码，等等。API key 是密码。在这方面绝对没有区别。

但是，在大多数情况下，至少出于以下原因，您仍然可能不应该这样做。

如果由用户选择，则密码为弱。如果您有许多用户，则许多用户将拥有123456之类的密码。容易猜出其中的一些。您无需在API应用程序中运行此风险，但是，在下一个请求中，在每个请求中发送该风险或仅勉强修改此风险都可以，但是这样做确实有点。

有时SSL/TLS有一些弱点。 确实确实会不时地公开一种针对TLS的新攻击，然后最终对其进行修补。但是，在一段时间内，攻击者可能会从加密流中推断出比特，如果部分了解加密内容(即通用密码)，则可能会变得更加容易。机会不是很高，但是问题是，有了许多TLS密码套件，攻击者可以立即记录流量，并在以后进行解密(因为它花费的时间很长，或者该方法尚未发明)。如果他只解密已经使用三年的API key ，那很好，但是如果它是用户密码...不太好。

服务器漏洞也可能是一个问题。前一段时间，openssl实现中存在一个漏洞，您实际上可以读取服务器内存的一部分(Web服务器进程)。如果网络服务器一直都收到用户密码，那么它可能会多次出现在内存中。如果这只是一个临时API key (或 session ID或其他内容)，那么对于攻击者来说值(value)不大。它仍然很好，但至少不是密码。

内部攻击者也要考虑。如果服务器上已有攻击者，则攻击者可能无法访问数据库以直接读取/修改凭据，但可以在有限的时间内观察Web服务器进程。与上述相同，如果他只能观察临时ID而不是实际密码，那就更好了。

如果要随每个请求发送密码，则需要将密码存储在客户端上。在客户端上存储敏感内容通常不是一个好主意，这为攻击者提供了可能性。通常最好的做法是，用户输入凭据，接收一个临时 token ，然后客户端忘记实际的密码，直到 token 过期，并且用户必须再次提供密码。从用户体验的角度来看，这当然可以接受也可以不接受-但是安全性始终是一个平衡。 :)

因此，您可以看到，在每个请求中发送用户名/密码不是直接的漏洞。实际上，它甚至在许多情况下都是可以接受的。但是您可以使用临时凭证来使其更安全，如果成本合理，为什么不这样做呢？