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

Question

我觉得从移动/网络应用程序到后端api的每个https请求发送用户名和密码是一个坏主意,但我不能提出太多好的论据.

在服务器中,我们将密码的哈希值存储在用户记录中.在任何情况下,在每个请求中我们都需要从数据库加载此用户记录,例如检查用户是否不仅仅被列入黑名单.由于我们需要加载用户记录的每个请求,因此比较密码并不需要花费任何成本,因此无需管理另一个sessionID或令牌数据库.

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

那么有什么好办法呢？

Answer 1

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

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

从技术上讲，用户名/密码与 API密钥之类的东西几乎相同，在有效期内它们是等效的。从某种意义上说，API密钥甚至更糟，因为根据实现的不同，通常将API密钥以纯文本形式存储在数据库中，而不是适当地散列密码（旁注，但是在散列时请使用bcrypt或pbkdf2之类的东西）。完全正确，可以在每次请求时以与API密钥相同的方式发送密码，也可以以相同的方式撤销密码，依此类推。等等。API密钥就是密码。在这方面绝对没有区别。

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

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

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

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

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

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

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