在服务器中,我们将密码的哈希值存储在用户记录中.在任何情况下,在每个请求中我们都需要从数据库加载此用户记录,例如检查用户是否不仅仅被列入黑名单.由于我们需要加载用户记录的每个请求,因此比较密码并不需要花费任何成本,因此无需管理另一个sessionID或令牌数据库.
此外,由于密码是通过https连接发送的,因此中间人无法捕获密码.即使中间有人能够做到这一点,当用户需要首次登录时他也可以这样做(因为无论如何他都需要在开始时发送他的密码)
那么有什么好办法呢？
这将成为一个很好的安全面试问题,因为它很好地衡量了安全领域的理解水平.不建议在每个请求中发送用户名/密码,但另一个答案甚至没有触及真正原因.
从技术上讲,用户名/密码与API密钥几乎相同,它们在有效时是等效的.从某种意义上说,API密钥更糟糕,因为根据实现,您通常会将API密钥明文存储在数据库中,而不是正确的散列密码(旁注,但请在散列时使用类似bcrypt或pbkdf2的内容).您完全正确,密码可以像每个请求上的API密钥一样发送,您可以以相同的方式撤销密码等.API密钥是密码.在这方面绝对没有区别.
但是,在大多数情况下,您仍然可能不会这样做,至少出于以下原因.
如果用户选择密码很弱.如果您有许多用户,许多用户将拥有123456等类似的密码.很容易猜到其中一些.您不需要在API应用程序中运行此风险,但是,在每个请求中发送它或者几乎不会修改此风险,但由于下一个要点,它会稍微改变一下.
有时SSL / TLS存在缺陷.它确实会不时发生针对TLS的新攻击,然后最终修补.但是,有一段时间,攻击者可能从加密流中推断出比特,如果加密内容是部分已知的(即公共密码),这可能会变得更容易.机会不是很高,但问题是,对于许多TLS密码套件,攻击者现在可以记录流量,并在以后解密(因为它需要很长时间,或者该方法尚未发明).如果他只解密已经过时3年的API密钥,那很好,但是如果它是用户密码……不太好.
服务器漏洞也可能是个问题.不久之前,openssl实现中存在一个漏洞,您可以在其中实际读取部分服务器内存(Web服务器进程).如果Web服务器一直收到用户密码,它可能会在内存中多次.如果它只是一个临时API密钥(或会话ID或其他),那么攻击者的价值就会降低.它仍然很好,但至少不是密码.
内部攻击者也需要考虑.如果您的服务器上已有攻击者,他可能无法访问数据库以直接读取/修改凭据,但他可能能够在有限的时间内观察Web服务器进程.与上面相同,如果他只能观察临时ID而不是实际密码会好得多.
如果要在每次请求时发送密码,则需要在客户端上存储密码.在客户端存储敏感内容通常不是一个好主意,为攻击者开辟了可能性.如果用户输入凭据,接收临时令牌并且客户端忘记实际密码通常会更好,直到令牌过期并且用户必须再次提供其密码.从用户体验的角度来看,这当然可能是可接受的 – 但安全性始终是平衡的.