Yes, password cracking works on salted hashes too. And the way you now describe it, with the entries in every column being hashed, and the column names themselves being meaningless*, I'm confused what value such a database has for anyone. They're just columns of random data, and the analyst doesn't even know what the data represents?

*And presumably, somehow, there being no way to recover this meaning. E.g. if an attacker is reversing hashes, they could try several sources of guesses - city names, country names, common first and last names in several languages, heights and weights in metric and imperial in the human range, valid phone numbers, IPv4 addresses, dates, blood type, license plate and post numbers or entire addresses, e-mail addresses if the attacker has a list of known-valid emails... all of these, and I'm sure many others that I forgot, are sufficiently small that they can be brute-force guessed by simply trying all possibilities, so no matter how generic the name of a column is, if it contains any of this data, the hashing can be reversed.

So this conversation has me thinking that I could go a step further and create a master list of all of the hashes, sort it, and then replace the hashes with their string containing their numerical index in the list. It just needs to be a 1-to-1 map. So maybe:

> Baltimore=>0x01a1...1ef7=>001 > Aaron=>0x17bf...86f1=>0002 >{"Foo":”Bar"}=>0x19f4...9af2"=>0003

This would be nearly impossible to reverse.

As for the utility... it doesn't break foreign key references. Null values still stay null... You can run the app, it'll just present you with gobbledygook.

So suppose the complaint is "two weeks ago workflow xyz started failing to complete, but never explicitly reached the failed state so we weren't alerted to the problem".

Before I could hash "xyz" and get the sanitized workflow name and then load the app with the sanitized name to see what stands out about it compared to its neighbors. Perhaps the dependencies on it's inputs are null or there's some should-never-happen scenario like a cyclic dependency. I don't need to know the actual names of the depended upon things to identify a cycle in them.

After this upgrade (?) I would not be able to hash the name that the user has given me, but I could still go looking for suspicious behavior during the time internal they indicated.

Privacy wise, the game is to be as effective as possible without having to ask them to share their screen. And when it's a bug, to have something to test with so we can say "it's fixed now" instead of "is it fix now? How about now?"

But remember rule #1 of data security: if there is a way to access the data legitimately, there is a way to access it illegitimately. The only question is the amount of time and effort required to do so.