Hash 散列+；盐业；胡椒粉+；远期关系

嗯，这个问题只是为了设计

2客户

ClientA

和

ClientB

用户可以使用其ID卡访问其办公室。此ID卡保存在数据库中，使用salt&pepper在客户端之间创建用户假名

ClientA DB

Username    String to be Hashed             Hashed Value
ClientA     UserIDCard1+E1F53135E559C253    72ae25495a7981c4062...
ClientA     UserIDCard2+E1F53135E559C253    a52e4f1565c90f048f8...
ClientA     UserIDCard3+E1F53135E559C253    59027bd9c8c8900d5c3...

Username    String to be Hashed             Hashed Value
ClientB     UserIDCard1+B7E459A02CB31F3C    b4b6603abc67096754...
ClientB     UserIDCard2+B7E459A02CB31F3C    e99c7e7f1389e40cd3...
ClientB     UserIDCard3+B7E459A02CB31F3C    16e78ad38eb1468edf...

ClientB数据库

Username    String to be Hashed             Hashed Value
ClientA     UserIDCard1+E1F53135E559C253    72ae25495a7981c4062...
ClientA     UserIDCard2+E1F53135E559C253    a52e4f1565c90f048f8...
ClientA     UserIDCard3+E1F53135E559C253    59027bd9c8c8900d5c3...

Username    String to be Hashed             Hashed Value
ClientB     UserIDCard1+B7E459A02CB31F3C    b4b6603abc67096754...
ClientB     UserIDCard2+B7E459A02CB31F3C    e99c7e7f1389e40cd3...
ClientB     UserIDCard3+B7E459A02CB31F3C    16e78ad38eb1468edf...

这意味着如果

UserIDCard1

访问

ClientA

，然后访问

ClientB

，UserIDCard1将被视为不同的用户，这有利于化名（如果攻击者访问数据库），但如果将来客户端决定合并ClientAB，则不利于化名

有没有一种方法可以在DBs中保留假名，但同时知道UserIDCard1是否在ClientA和ClientB的大楼中？或者根据定义，散列+盐不是能够比较散列值的

编辑

---

这些数据库的目的是通过存储用户的“用户ID卡”来获取关于客户用户的匿名统计信息，而不会损害不同数据库中用户的隐私。

这不是一个salt，而是一个salt作为每个条目的新值。整个db的单个值有时被称为“胡椒”，但它不能提供真正的盐所能提供的保护。关于这种设计的一个问题。接口无法广播其客户端ID有什么原因吗？如果是这样，那么您可以在DB表中为这些用户存储一个client_id字段。salt在每个卡/客户端对上可以是唯一的，这也使得它比在每个客户端的所有用户上重新使用单个值更强。@CorvusCrypto你是说UserID吗？我之所以不在数据库中保存UserID，是因为它可以很容易地附加到一个人身上，并且可能会引起隐私问题。另外，这个数据库的目的是获取匿名信息，比如流量或平均签入/签出时间，诸如此类。啊，我现在明白了。多有趣：）我会喜欢这个，再想想。