My server will be receiving data from several hundreds of computers. As part of keeping track of which computer sent what, I will be fingerprinting the hardware and keeping the results in my database.
Nowadays the most sensible source to use for that is the SMBIOS UUID. These 128 bit numbers are set by motherboard manufacturer and are supposed to be unique, but not so much unpredictable. For example, the last part often contains the MAC address of the onboard NIC, and several bits of those are manufacturer specific.
Because I don't gain much by knowing the exact UUID, I'm fine with using a hash. That would already introduce some privacy. However, since (without further measures) hashes can be calculated quickly, and those UUIDs do not actually provide 128 bit of entropy, I suppose it would be feasible to trace the hash back to some UUID.
Would it be worth introducing a more expensive hash function to prevent the above, in case my server would be compromised? I don't think I would be able to use salt with it, because I can't store the salt in the hardware and the data is supposed to come in already hashed (not to ever communicate the actual UUID). On the server I should be able to group data coming from the same source. How useful could it be to know the UUID of some computer, that you might also know belongs to a particular company or individual?
The derived ID to be used needs to survive reinstalls of the system, so a purely software-based alternative won't do. Introducing custom hardware (e.g. hardware key/dongle) is not an option. Other ideas I've had, of which I'm not sure how good they are:
- Deliberately shortening the hash to the point that is still unlikely to encounter the same hash more than once for a single user (so I'll still be able to distinguish their systems) while no longer preserving enough entropy to be reversible - I'm not sure what the appropriate length would be and how much of an improvement it is if instead of an actual UUID, one could establish a rather limit set of potential UUIDs
- Adding a little bit extra hardware to the hash, at the cost of it becoming more likely to change, but increasing the entropy of the source somewhat