It's possible to intentionally alter data that a hash has been computed from in such a way that it still computes to the same hash. Hashing alone is a weak way of ensuring that data has not been altered.
It is extremely hard to break cryptographic hash functions to the point it is considered impossible. If you could do that, then you could be breaking into all sorts of systems. Cryptographic one-way hash functions are actually the preferred way to secure passwords.
It isn't trivial, but it's not as hard as you make out. In the case of real estate which is often worth a great deal of money, plenty of people will be willing to put the effort in to do this.
> If you could do that, then you could be breaking into all sorts of systems.
Absolutely. And this is one of the methods that is used to do just that. I'm not talking about a theoretical security issue here, this is a weakness that has been leveraged in the real world for a long time.
> Cryptographic one-way hash functions are actually the preferred way to secure passwords.
Yes, but they're also not considered bulletproof. They're a bit of a compromise effort. That's why the leaking of password files is considered a security problem even when the passwords are salted hashes.
And, like with password hashes, it's not actually necessary to break the hash in order to alter the hashed record while maintaining the same hash. There are mathematical shortcuts to doing this, but you can even just brute force it if you have enough computing power or time.
> Absolutely. And this is one of the methods that is used to do just that. I'm not talking about a theoretical security issue here, this is a weakness that has been leveraged in the real world for a long time.
Oh really? Care to share some examples of SHA-256 and SHA-3 collisions?
Not sure what would count as examples here, honestly. The ones I know of were what I encountered when I was working in cryptographic security, and I don't think any of those incidents were made publicly available.
That said, there are readily available tools that use things like rainbow tables to "crack" SHA-256 salted password hashes. By "crack", I mean to come up with a password that hashes to the same value.
Yeah, I didn't think so. :) I know of no single incident of SHA-256 or SHA-3 having collisions successfully generated.
Cracking SHA-256 with rainbow tables is a fundamentally different exercise as you are relying on someone having selected a weak password that you can then generate a hash for. The weakness is not in SHA-256, but in the weak user selected password.
> I know of no single incident of SHA-256 or SHA-3 having collisions successfully generated.
That's fine, I don't expect you to believe me without evidence. But I have seen this happen more than once in my work.
> you are relying on someone having selected a weak password
Stated another way, you are relying on having some idea of what the original data looked like, so you can reduce the search space. Absolutely correct.
However, if you're hashing public records like real estate, where you literally have the clear text, that's a much simpler problem than cracking passwords. All you need to do is alter the document in the way that you want, then find what other changes are needed to create a collision with the original hash. This is not very computationally intensive compared to password cracking.
Add in that the amount of money on the line with real estate can be high enough that it would make it worth throwing serious resources at it -- more than the average password cracker could even begin to summon -- and my confidence in the security of the hashes is greatly reduced.
