我意识到，一般来说，您不应该直接存储用户凭据（即以纯文本形式）；相反，最好存储它们的某种加密形式。
但是，假设我创建了一个与其他第三方网站交互的网站；假设这个第 3 方站点提供了一个 API，需要用户的凭据（使用该站点）进行身份验证。
如果我的目标是提供卓越的 UI 或在第 3 方提供的服务之上引入附加功能，那么在我看来，我需要以某种方式实际存储用户的凭据，以便我可以使用 API，而不是用户的密码my站点（我可以对其进行哈希和加盐），但对于外部站点。
有没有“正确”的方法来做到这一点？我最初的想法是以某种形式加密存储凭据，以便可以在服务器上解密它们，以便对第 3 方服务进行 API 调用。这意味着攻击者需要了解加密/解密的工作原理才能窃取用户的外部密码。然而，这对我来说似乎并不那么牵强；一个聪明的黑客已经破坏了托管我的应用程序的服务器，他可能能够轻松获取代码并找出答案。
因此，这种方法似乎总比没有好，但并不是很好。人们还使用其他策略吗？这整个概念（与需要用户凭据的第三方服务交互）是否不明智？
我必须相信至少有一些相当安全的方法来处理这种情况，因为即使在一些相当知名的网站（例如 Mint.com）中，它似乎也相对常见。
Update：只是澄清一下：我知道在理想的情况下，第 3 方服务将实现某些版本的 OAuth（或等效版本），这样我就不必存储凭据。不幸的是，这种情况下的实际情况是，第 3 方服务要求在每个 API 请求中发送用户名和密码。那么，我听到的共识是，在这种情况下，大多数开发人员会拒绝使用该服务（并且很可能建议他们实施 OAuth）？
IMO认为你应该not take 责任将凭证存储在某处your文件系统。想想看，即使是第 3 方服务器也可以not知道用户凭据（将具有密码的哈希值，而不是存储的实际密码）。
我建议将它们存储为 http 会话的一部分，只要会话处于活动状态，该会话就会持续存在。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
