这似乎可以简单地分解为；

• 我有一个包含明文密码的作业队列。
• 我想阻止其他服务器用户访问这些密码。

假设“其他服务器用户”并不意味着超级用户帐户，这似乎应该很容易。

您需要做的是对其进行设计，以便您的frontend <-> jobqueue链接充当二极管，作业能够进入，但没有数据可以从作业队列中流出前端方向。

一些简单的例子；

• 作业队列存在于前端无权访问的数据库中。数据在运行时生成的密钥下加密。
• 作业队列仅存在于标记为不可追踪的进程中的 RAM 中（在 Linux 中，您将需要AppArmor，我相信这可以通过删除功能来实现CAP_SYS_PTRACE）
• 作业队列不存在 - 使后端调用同步。

也就是说，除了立即散列明文密码之外的任何操作都是反模式恕我直言。

您应该使用bcrypt对密码进行哈希处理，并在明文到达前端的 API 服务器后立即丢弃它。

对于第三方 API 密码，请使用加密安全的伪随机数生成器生成一个长随机密码，并将其存储在用户记录中。根据此 API 的敏感性，您可能希望在将 API 密码存储到数据库之前对其进行对称加密。如果您想加密 API 密码，我建议使用Keyczar来管理加密。

我不明白为什么您将相同的密码传播到第三方 API。这不是单点登录。那是单一密码愚蠢。

而是散列他们的密码并存储它。然后为用户生成一个随机密码，每个第三方登录一个。并使用它登录。这样，只有单个站点密码进入队列。

看看你的实际问题：这是不可能的。我假设作业队列和后端 API 在同一台服务器上。如果你不信任队列的安全性，你也不能真正信任后端的安全性。而且您必须以某种方式存储密码，以明文形式或服务器可以从中提取明文密码的格式。

这个答案与之前建议您应该散列密码、将其存储在数据库中等的问题不同。这些解决方案在我看来是不必要的复杂。

如果您在任何地方都在前端使用第 3 方 API ，那么您可以/应该自己播种和散列密码，然后简单地将散列后的 blob 发送到后端。一种方法可能如下所示：

1. 使用 BCrypt / Scrypt 对密码进行哈希处理

2. 将该哈希作为用户密码发送到后端，并在用户更改密码时更新它。

3. 对您的身份验证网络服务器使用相同的哈希解决方案

换句话说，不要向第 3 方 API 发送明文密码，而是向他们发送您创建的哈希值。只需确保在每个验证网络服务器或网络服务上重新创建此哈希格式即可。

然后，当您将身份验证请求代理到 3rd 方 API 时，获取 HTTPS POSTed 明文 PW，对其进行哈希/种子处理，然后将其发送到 API 以进行进一步验证。

这种方法将防止队列的随意观察者冒充用户，并且盐将防止创建彩虹表。