我意识到，一般来说，您不应该直接存储用户凭据（即，以纯文本形式）；相反，最好存储它们的某种加密形式。
但是，假设我创建了一个与其他第 3 方网站交互的网站；假设这个第 3 方站点提供了一个 API，该 API 需要用户的凭据（使用该站点）进行身份验证。
如果我的目标是，比如说，在这个第 3 方提供的服务之上提供一个卓越的 UI 或引入额外的功能，那么在我看来，我需要以某种方式实际存储用户的凭据，以便我可以使用 API——而不是我的网站的用户密码（我可以散列和加盐），但用于外部网站。
有没有“正确”的方法来做到这一点？我最初的想法是以某种形式存储加密的凭据，以便可以在服务器上对其进行解密，以便对第 3 方服务进行 API 调用。这意味着攻击者需要了解加密/解密的工作原理才能窃取用户的外部密码。但是，这对我来说似乎并不牵强。一个聪明的黑客已经攻破了托管我的应用程序的服务器，他可能能够很容易地获取代码并找出它。
因此，这种方法似乎总比没有好，但并不完全好。人们还使用其他策略吗？这整个概念（与需要用户凭据的第 3 方服务交互）是否不明智？
我必须相信至少有一些相当安全的方法可以处理这种情况，因为即使在一些相当高知名度的网站（例如 Mint.com）中，它似乎也比较普遍。
更新：澄清一下：我知道在理想的世界中，第 3 方服务将实施某些版本的 OAuth（或等效版本），这样我就不必存储凭据。不幸的是，在这种情况下，第 3 方服务要求在每个 API 请求中发送用户名和密码。那么，我听到的共识是，在这种情况下，大多数开发人员只会拒绝使用该服务（并且很可能会建议他们实施 OAuth）？