嗯，这个问题仅适用于设计方案。
2个客户ClientA和ClientB用户可以使用他们的ID卡访问他们的办公室。此IDCard使用salt＆amp; pepper保存在数据库中，以在客户端之间创建用户假名。
ClientA DB
Username String to be Hashed Hashed Value
ClientA UserIDCard1+E1F53135E559C253 72ae25495a7981c4062...
ClientA UserIDCard2+E1F53135E559C253 a52e4f1565c90f048f8...
ClientA UserIDCard3+E1F53135E559C253 59027bd9c8c8900d5c3...
ClientB DB
Username String to be Hashed Hashed Value
ClientB UserIDCard1+B7E459A02CB31F3C b4b6603abc67096754...
ClientB UserIDCard2+B7E459A02CB31F3C e99c7e7f1389e40cd3...
ClientB UserIDCard3+B7E459A02CB31F3C 16e78ad38eb1468edf...
这意味着如果UserIDCard1访问ClientA然后ClientB，则UserIDCard1将被视为不同的用户，这有利于假名化（如果攻击者可以访问数据库）但如果将来客户决定合并ClientAB，那就太糟糕了。
有没有办法在DB之间保持假名，但同时知道UserIDCard1是否在ClientA的构建和ClientB的构建中？或者根据定义，Hash + Salt NOT 能够比较散列值吗？
修改
这些数据库的建议是通过存储他们的用户ID卡来获取有关客户用户的匿名统计信息，而不会影响用户在不同数据库中的隐私。