In the FAQ ( https://ask.vrchat.com/t/age-verification-faq/28458 ) it is stated the purpose of storing an ID hash is to: --- Detect duplicate IDs: When someone submits a verification, we compare it against our existing hashes. If we find a match, we know that ID has been used before and can reject the verification. Enforce bans: We can check if an ID was previously associated with a banned account, preventing banned users from verifying new accounts with the same ID. Enable multiple accounts: We can allow users to have more than one verified account using the same ID. Previously, this would have required keeping your full ID data with Persona. While this is not planned for initial launch, we are considering the feedback that you have given us. --- This indicates that you will be storing some sort of mapping between the hashed data (which you have not clarified what data is being used in this hash, please do so) and a VRC account. This is bad. While hashing data with a salt is a one way action, it is brute force-able. With time and resources (the amount of which decreases as technology progresses) these hashes can be cracked. Salting makes this not viable on a wide scale (cracking every hash in a leak at once), but targeted cracking is still very possible. If this database of hashes leaks (assuming the pepper leaks along with it), anyone with a grudge can dedicate time to crack a specific hash for the user that they have a grudge against. Likewise, high profile users like creators/vtubers are at high risk due to simply being more known. There is also not a ton of actual information stored on the ID itself, and much of it is in predictable formats (ie: dates, names, address, etc). Not to mention that supporting every ID type likely means that only a subset of this information will actually be used for the hash. This lowers the entropy of the input to the hashing function making it easier to crack a specific hash. Storing more sensitive data to increase the entropy is a cyclical loop, in that it presents more risk in the event of the hash being cracked. Storing an association between the hashed data and a VRChat account is not required to do 2 of the 3 goals of storing the hash: --- Detect duplicate IDs: No association is required to do this, you simple store the hash itself, and check against all hashes for each new ID added. You would have to do this anyway. Enable Multiple Accounts: If you choose to do this, you can simply stop checking against your hash store, delete hashes you have, and stop storing new hashes. Alternatively, If you would like to limit the number of accounts that can be used under one ID, you can continue the same way, but also store a value with the hash that represents the number of times it has been used to verify. Enforce bans: This one does not have a solution. However, this relies on VRChat having already allowed users to verify multiple accounts with one ID. This also assumes that the person is verifying under their own identity to begin with, which is made less likely by the previous sentence. Abusers of this system would also likely rack up many verifications/accounts as they would have to keep verifying as they got banned over and over. If a limit is in place for how many accounts can be verified under one ID, it would be reached. If there is no limit, that number would still climb higher than a normal user of the platform, warranting further investigation. --- Overall, if any sensitive information is planned to be used to generate the hash, IE: Name, ID#, address. Then I personally think storing the hash with an association to a VRChat account is dangerous, and should not be done. It is not really required to do the main purpose of storing a hash in the first place, preventing ID reuse, and increases risk to users in the event that the hashes are leaked. If no link between a specific VRChat account and their hashed private information is stored, then no individual VRChat user is identifiable.
