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
  • Could you not just generate a unique UUID that is cryptographically random for each device and store it somewhere locally, or is it a no-touch sort of deal?
    – Steve
    Commented Oct 15, 2015 at 22:03
  • @Steve I need the ID I will end up using to survive both reinstalls of the system and common changes in hardware. To do what you suggest, I would need to have hardware dedicated to this purpose, e.g. a hardware key/dongle but that is impractical. (In fact I will use an ID like you suggest as well, but the HardwareID I'm discussing serves to relate SoftwareIDs whenever those change for reasons mentioned earlier.) Commented Oct 15, 2015 at 22:12
  • What would an attacked gain by cracking these hashes? Do not shorten the hashes, that's always a bad idea
    – Allison
    Commented Mar 5, 2018 at 5:25
  • @Sirens I don't know; that's part of the question. If I had a clear view of all ways to potentially exploit it, I'd know how valuable it is. But just that I can't think of any meaningful ones doesn't mean there isn't. How is shortening the hashes a bad idea? In this way, they still provide enough entropy for my use case (to keep a relatively minor number of system apart) but not enough to be reversible to an actual UUID. Commented Mar 5, 2018 at 17:24

1 Answer 1

  1. You can at least add application specific salt (hard-coded in the app), so building a rainbow table just for your small database is not worth it.
  2. You can use a slower hash function (pre-compute the hash only once per app start).
  3. Adding more entropy if possible for your application would help greatly.
  4. If at all possible, do not associate the hashes with identifiable information, or make the association hard, for example requiring the user password to decrypt his UID hash. (for more suggestions, we would need to know more about what you need it for)

Shortening the hash may help in some cases but could be detrimental in other. IMHO it would not do much in a situation where the UID is associated with other information such as IP, or Name/Company.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .