我意识到一般情况下，你不应该直接存储用户凭证（即以纯文本形式存储）;相反，最好存储一些加密形式。
但是，假设我创建了一个与其他第三方网站互动的网站;并且让我们说这个第三方网站提供的API需要用户的凭据（使用该网站）进行身份验证。
如果我的目标是提供优质的用户界面或在第三方提供的服务之上引入其他功能，那么在我看来，我需要以某种方式实际存储用户的凭据，以便我可以使用API而不是我的网站的用户密码（我可以哈希和加密那个），但是对于外部网站。
是否有＆＃34;权利＆＃34;这样做的方法？我最初的想法是存储以某种形式加密的凭证，以便可以在服务器上对它们进行解密，以便对第三方服务进行API调用。这意味着攻击者需要了解加密/解密如何工作才能窃取用户的外部密码。然而，这对我来说似乎并不那么牵强;一个聪明的黑客已经破坏了托管我的应用程序的服务器可能会得到代码并很容易解决它。
所以，这种方法似乎总比没有好，但不是很好。人们使用其他策略吗？这整个概念（与需要用户凭据的第三方服务交互）是不明智的吗？
我不得不相信至少有一些合理安全的方法来处理这种情况，因为它甚至在一些相当高调的网站（例如Mint.com）中似乎相对普遍。
更新：只是为了澄清：我知道在理想的世界中，第三方服务会实施某种版本的OAuth（或等效版本），这样我就不必存储凭据。不幸的是，在这种情况下的实际情况是第三方服务要求在每个API请求中发送用户名和密码。那么，我听到的共识是，在这种情况下，大多数开发人员会拒绝使用该服务（并且很可能建议他们实施OAuth）？
答案 0 :(得分：5)
IMO认为您应该不将责任存储在您的文件系统的某个位置。试想即使是第3方服务器也不知道用户凭证（将使用密码的哈希而不是存储的实际密码）。
我建议将它们存储为http会话的一部分，只要会话处于活动状态就会持续。