I'm having a friendly debate with someone who thinks that a website can safely make public sensitive data about it's users as long as that data is hashed (don't ask why, it's a long and hypothetical story). My position is that this opens the data up to brute-force attacks at least and that no hash is truly unbreakable given enough time and resource, therefore even hashed data should be protected and kept private. Who's (more) right? Can private data safely be made visible in public as long as it is hashed, or not?

4 Answers 4


You are correct that brute force attacks are feasible, especially if the data being hashed comes from a relatively small search space. Here is a recent example where New York cab details were inadequately disguised using a hash. From the article:

It turns out there's a significant flaw in the approach. Because both the medallion and hack numbers are structured in predictable patterns, it was trivial to run all possible iterations through the same MD5 algorithm and then compare the output to the data contained in the 20GB file. Software developer Vijay Pandurangan did just that, and in less than two hours he had completely de-anonymized all 173 million entries.

Note that it is not the use of MD5 that is the problem here. Any hash algorithm could be brute forced in exactly the same way.

It may be possible to render the hashing irreversible by adding salt before hashing; however at that point you would do just as well to create a lookup table mapping sensitive data to entirely random values—then there will be no hash algorithm to break.

Of course this all assumes that there are associations in the data that you wish to preserve after anonymising. Otherwise the safest approach is to entirely omit or mask any sensitive data.


plain hash is not secure if the attacker plans to retrieve some passwords using a rainbow-table attack (or other brute force techniques). Appending the salt should make the hash reasonably secure, even if released to the public.

"unbreakable hash" doesn't make sense. If you use a weak password (e.g. "123456") and don't use salting any strong hash function become "weak".


If you're hashing arbitrary data, there's no easy way to reconstruct it, since it doesn't have a predictable pre-hashing size. The reason password hashes that aren't salted are dangerous when leaked is because you're dealing with a very constrained set of possibilities. Without a salt, the password of "password" will always result in the same hash. This allows an attacker to start with common password and see if there are any matches, which there often are. If you take data of an arbitrary size and hash it, you can't reasonably guess what its original content was. Imagine taking a 1 megabyte file and reducing it to a 16 byte MD5 hash. Without any other information about the data, there is no realistic way to turn that hash back into the original information.


It really depends on the sensitive data and by what do you exactly mean with "hash".

As a simple escape, let's say we have a person X where we store his or her religion and sex. The possible options for religion are "christian", "muslim", "other" and "atheist". And the options for sex are "Male", "Female" and "Other". The sex or religion of a given person are declared sensitive personal information under some jurisdictions so there's no need to argue if this data is sensitive.

No matter which (static) hashing algorithm you use, it's not safe to publish data about X where sex is "b10331548e56c6ea29c862be63ef4643" and religion is "d4d2ff930bd49340c8fc89b15a2db1e9" because the possible input set is so small that you can simply iterate all options and figure out mapping from the actual data to published hash. Also note that even if you don't know all the input values or the hash, you may still know details of some another user in the same database and if they share the same hash for e.g. "sex" you know the actual data because hash is the same.

However, with a proper algorithm it is safe to output signatures. For example, if you have secret signing key and each person has unique ID, you can use e.g. like HMAC-SHA256 and use catenated string {secret signing key, ":", unique person ID} as the key for HMAC-SHA256 it's safe to publish the signature of the data which looks like plain SHA256. Note that this still requires that you do not share the secret signing key and that it has at least equal entropy to your signature algorithm (that is, minimum entropy of 256 bits for SHA256). Note that nobody can correlate any data values using those this kind of hash output so publishing the output of this algorithm is suitable only for transferring opaque signatures that only you can verify.

Also note that you also need to include version number in the person data and include it in the signature key if you have to hide the fact that the given data value matches historical value for the same user. If it's okay to leak that field Y was set to some value Z, then changed to another value and then returned to original value Z you don't need to version or timestamp the signatures.

You must log in to answer this question.

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