我遇到了一个奇怪的加密问题，我可能赚得比需要的要多，我会把我目前的低烧归咎于这个问题。我只是真的很不喜欢在没有至少一些审查的情况下在任何与加密货币相关的问题上推出自己的解决方案。
我正在实施用于集成第三方服务的 SSO 解决方案，其中我根据我们自己的身份验证平台对用户进行身份验证，当用户正确进行身份验证时，该平台会向我返回有限数量的一致可用变量。
保证始终代表给定用户的其中之一是他们在我们网络上的login ID。在此上下文中允许的其他任何内容都不能保证对给定用户保持不变。
我无法将login ID以明文形式存储在第三方服务上作为共享令牌。（在你质疑为什么之前，有一个非常简单的原因：法律不喜欢它......虽然此标识符是专门为不对 FERPA 敏感而创建的，但它基本上只被删除一次）
我可以散列它。由于大概有一个很好的理由不将其存储在明文中的其他地方，因此我想至少合理地对其进行哈希处理。通常，如果给定用户还有其他一些非敏感标识符，我可以加密敏感信息（例如，如果它是密码）并将该 salt+hash 和 PK 非敏感标识符存储在表中，然后在进行比较时根据非敏感标识符进行查找。
如果没有非敏感标识符来执行检索，似乎我只会在没有唯一盐的情况下进行基本的哈希操作（我仍然可以使用它们）。我存储在自己的数据库中的任何内容都与作为令牌传递的内容一样容易受到攻击，因此创建原始login ID到加盐和散列login ID的映射表是没有意义的。盲目地针对我存储的每个盐+哈希测试给定的哈希值将是荒谬的。
我可以继续用login ID的胡椒粉来SHA2并称之为一天（毕竟，这些"只是"登录ID而不是密码 - 并且该解决方案被认为至少足够），但我想知道这种情况是否有更好的解决方案？
我想你应该知道这一点：美国教育部给威斯康星大学里弗福尔斯分校的信：
我们认为 FERPA 允许机构指定和披露 作为"目录信息"的唯一个人标识符，例如 学生的用户或帐户登录 ID（或用作 登录ID），只要标识符不能单独使用， 未经授权的个人访问非目录 来自教育记录的信息。换句话说，如果学生必须 使用共享密钥，例如 PIN 或密码，或其他机密 学生独有的身份验证因素，以及他们的个人 用于访问学生信息中记录的标识符 系统，则该标识符可能被指定并披露为 根据要求根据 FERPA 提供的目录信息 条例第99.37条。（津贴适用于学校官员 单独使用学生公布的个人标识符，就像他们一样 使用学生的姓名来获得对学生教育的访问权限 记录，前提是学校官员具有合法的教育背景 根据法规§ 99.31（a）（1）的利息。
相反，如果一个机构允许学生接受自己的教育 使用个人标识符但不使用密码的记录 或其他因素来验证学生的身份（或者如果 标识符本身也用于验证学生的 身份），则该标识符可能不会作为目录披露 FERPA 下的信息，因为它可能导致披露 将信息保护给学生以外的人，因此会 "如果披露，则有害或侵犯隐私"。（一些 机构可以继续使用学生的"官方身份证号码" 这种方式。根据这种推理，一个允许 学生（或任何其他方，就此而言）获得访问权 通过仅提供公开信息来记录教育， 例如学生的姓名或公布的电子邮件地址，没有任何 身份的其他证明或身份验证，可能具有策略或 违反 FERPA 的做法，因为它可能导致披露 教育记录给未经授权的收件人。
但是，如果这不可接受，请考虑使用临时的额外 ID（共享机密）。
您可以使用临时分配给用户的随机令牌（以胡椒时间和用户 ID 为前缀，以避免必须检查冲突），这些令牌临时分配给用户（很可能通过某种查找表）并在合理的时间间隔内清除。
如果您仍然不想要与用户绑定的任何内容，即使是暂时的，您将无法使用哈希，因为哈希是不可逆的。您将被困在针对每条记录测试哈希值的困境中，这在技术上是不可行的。
最后，您可以使用哈希 + 随机令牌和用户 ID，类似于 SSO，但使用存储在服务器上的代码或配置中的密钥对用户 ID 进行加密。这样，攻击者必须同时获得对数据库和代码或配置的访问权限才能使用数据。理想情况下，每天更改密钥。
当前实施的解决方案
该login ID目前正在通过一系列算法运行，以创建一种独特的盐，该盐可以在运行时基于给定的原始login ID再生，从而实现可重复的查找过程。用盐和胡椒粉，login ID被散列。
已知问题
低熵（仅依靠login ID的固有熵）和创建盐的算法过程严重限制了这个加密过程的强度：了解创建盐的过程和胡椒的价值，就有可能为这些哈希创建一个彩虹表。尽管如此，任何标准的预生成彩虹表都不起作用：它必须为这组哈希自定义完成，并且需要足够的编程知识/足够灵活的生成器来复制盐创建过程。使用 bcrypt 和自定义盐例程有望使该过程比检索相关值更耗时。
不幸的是，这本质上是通过默默无闻、按程度获得安全。但这是我目前能想到的最好的。
进一步考虑
根据 Marcus Adams 的回答，一种可能提高安全性的可能性是将散列login ID存储在查找表中，然后仅将完全随机/唯一的 GUID 样式令牌传递给第三方软件以用于 SSO 目的。这将消除在传输中拦截散列login ID的机会（一开始相对较低，因为每一步都是通过https进行SSL编码的，并且散列login ID在发送之前被折叠到通过rijndael和PSK加密的SSO有效载荷中）。虽然这消除了第三方妥协导致潜在违反login ID的可能性，但它只会将这种潜力转移到我们的系统，我们不能假设它一定更安全。鉴于当前的解决方案需要对源代码进行妥协以找到胡椒和盐算法，并且考虑到任何此类妥协也能够揭示任何数据库密钥，就任何潜在的完全妥协而言，使用查找表似乎没有真正的附加安全性。
对我所实施的攻击风险的更深入分析超出了我自己的加密知识或我目前有时间投入的内容。