以可检索方式存储密码的最佳方法可能是使用对称密码对其进行加密。将密码存储在打算仅以加密形式使用它们的设备上，然后可能在服务启动时有用于解密 API 密码的密钥通过外部方法派生（您自己输入密码，检索它来自未连接到网络的外部计算机等）。

一旦解密 API 密码的密钥仅加载到内存中而不是放在磁盘上，您就可以根据需要使用它来解密 API 密码。确保将明文密码也保存在内存中，并在使用后覆盖它们。

好吧，如果它是文字密码，这是因为某些 api 需要它一次吗？通常，更现代的身份验证形式会绕过直接密码，并且会将用户重定向到第三方身份验证机制以及 API 密钥。然后 Ali 提供商会将一个身份验证令牌传回您的站点，您可以将其用于 API 调用。

如果它是私人密码（例如类似于 SAP 数据库的密码），那么您可以简单地锁定该文件。

但是，如果您必须直接向用户询问他们的密码，以便您可以使用其他一些后端代码，那么这对我来说只是闻起来有点滑稽，我的直觉会说必须有一些更好的方法。

以文字形式存储密码通常是一个坏主意。如果您束手无策，请至少尝试使用混淆代码即时计算密码；如果二进制文件被泄露，这至少会阻止自动化和低级黑客。

首先，任何解决方案都不会达到密码存储最常见的级别，因为您作为服务将需要访问客户的密码。

由于您自己不提供攻击向量，我将假设您想要防止最常见/最容易实现的数据库访问。（具体的读取访问权限，但对于这种情况并不重要。）

为了防止这种情况，在将密码发送到数据库服务器之前对其进行加密，并且不要将加密密钥存储在数据库或数据库服务器上。我认为有一个只处理加密/解密和 API 调用的服务器。然后有尽可能强大的防火墙规则“围绕”它，理想情况下我会说不要让这个服务器直接访问数据库服务器，以限制它与您的另一个应用程序服务器的通信，当然还有 API 所需的访问权限来电。

这种方法将使攻击者需要破坏此加密/解密机器，并且如果他想获得特定用户的密码，还需要破坏您的数据库（或其他应用程序服务器）。它还有助于将您的其他保护措施集中在此服务器和代码上。就像在这个服务器上运行的应用程序的代码审计一样，另一个让这个应用程序的功能尽可能受限的原因。