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