0

因此，这个问题正在深入研究安全和加密，而这个问题可能很多人都没有遇到过。答案可能是理论上的。让我概述一下场景...

  1. 网站前端通过后端 API 驱动。后端有一个端点处理通用注册表单username和password。它使用 SSL。
  2. 后端 API 通过异步作业队列处理注册。队列不向 API 服务器返回响应。这是一个设置和忘记操作来排队注册。
  3. 排队的工作由工人接走。工作人员负责创建用户帐户。这些工作人员需要访问明文用户密码，以便他们可以使用密码触发第三方 API 注册调用。

因此，问题的真正症结在于将密码同步到第三方 API，同时又不将其泄露给窥探者。队列带来了无法再从全局 POST 数据中直接访问明文密码的问题，这意味着它需要以某种方式存储在队列中。

队列可以轻松存储散列密码并将其直接复制到用户表中。但是，此解决方案不允许将密码与第三方 API 同步，因为它已经加密。我玩弄了双向加密，但我全心全意地担心让密码容易被攻击者解密。

有人能想出一种安全的方法来处理这种密码同步情况吗？

队列是一项要求，并且假定任何有权访问服务器的人都可以读取该队列。密码不一定要同步；第三方 API 的密码可以是原始 API 的派生，只要有一种安全的方法可以通过登录用户解密而不提供密码。这本质上是用不支持 SSO 的第三方 API 模拟单点登录。

4

1 回答 1

0

有几种方法可以同步密码：

  1. 两个身份验证存储都使用可逆加密，以便每个系统都可以提取真实值以发送到另一个系统；
  2. 两者都使用完全相同的加密，以便您发送加密的文本，因此两者都可以理解。
  3. 一个系统是“主”系统，用户始终通过该系统进行身份验证，而“从属”系统仅接收用户已登录的确认。这可以采取由主系统创建的机器生成密码的形式，用于在奴隶。
  4. 一个系统是所有其他系统调用以进行帐户验证的“主系统”。类似于使用 LDAP 或 MyOpenID。

使用多主密码同步肯定会遇到一些问题，例如确保在用户更改密码时正确复制密码更改。

在您的情况下，听起来用户从未直接与第 3 方 API 交互。如果这是准确的，请让用户针对您的系统进行身份验证。需要时生成第 3 方 API 密码，将其与他们的帐户一起存储，并在必要时将其自动登录到其他系统。您的主密码可以以不可逆的加密方式存储；但是，第 3 方必须使用可逆加密。队列永远不必拥有初始密码，而只需生成一个新密码并将其存储在本地帐户中。

于 2013-03-12T20:41:06.893 回答