5

Hash values are also useful for verifying the integrity of data sent through insecure channels. The hash value of received data can be compared to the hash value of data as it was sent to determine whether the data was altered. Source.

A common approach used in data transmission is for the sender to create a unique fingerprint of the data using a one-way hashing algorithm. The hash is sent to the receiver along with the data. The data's hash is recalculated and compared to the original by the receiver to ensure the data wasn't lost or modified in transit. Source.

If the hash of some data is computed and sent along w/ the data, can't an attacker alter the data, re-compute the hash and the receiver would be none the wiser?

spottedmahn
  • 153
  • 6
  • 2
    You skipped over the all-important line: "You can sign a hash value more efficiently than signing the larger value." – schroeder May 26 '20 at 18:25
  • this is exactly why putting the sha next to the download link is absurd. – dandavis May 26 '20 at 19:54
  • 6
    I believe the "altered in transit" may refer to transmission errors, not an active attacker changing the data. Transmission errors would be detected by the hash. – ThoriumBR May 26 '20 at 21:00
  • @Machavity That's unrelated. To save everyone a click: that's about storing the salt alongside a password, nothing to do with using a hash for integrity or authenticity checks. – Luc May 27 '20 at 08:08
  • 6
    @dandavis No, see zyk's answer: the website you get the hash from is the secure channel: it has the right domain and uses https (presumably), so that should be right. The download file itself can be served from mirrors (or a CDN). This is similar to how `apt-get` works: you get pgp keys baked into your distribution (with the iso whose hash you get from the distribution's website) and the package downloads themselves can be plain HTTP from various mirrors hosted by all sorts of third parties. – Luc May 27 '20 at 08:11

3 Answers3

8

The source explains an overarching concept and is perhaps slightly ambigious rather than outright misleading. Hashes sent alongside data in their "raw" format are definitely susceptible to a tampering attack and, therefore, we need to either:

  • Share the hash value out-of-band: A simple example is downloading a file off a website which shows the file's hashsum on the web page next to the download link (the out-of-band channel here is the web page content being served within a different communication channel or even better served by a different web server). Once you have successfully downloaded the file, you would calculate the hash of the file independently and compare the hash to ensure integrity. This is a common practice for critical files such as an operating system image.
  • Authenticate the hash sent along with the data: this is done by using what is known as a Hashed Message Authentication Code (HMAC), which provides both the "integrity" and "authenticity" security services to your message. There are a lot of detailed answers about this topic here.
zyk
  • 409
  • 1
  • 3
  • 11
  • 1
    Good answer zyk :) And you're right about M$ not being intentionally misleading of course, but who can pass up an opportunity to jab at a bigtech? – Luc May 27 '20 at 07:19
  • HMAC, or something basically equivalent to it, is a fairly common pattern in webservice API's, where an integrator is given both an API key and an associated secret key. So long as the shared secret key isn't compromised it can be used to verify that requests and responses haven't been altered in transit. – aroth May 27 '20 at 12:01
  • Yes I don't blame you @Luc...I was only being politically correct :) Thanks for the thumbs up! – zyk May 27 '20 at 18:09
3

Your source is misleading (Microsoft misleading, who'd have thought!). You cited this:

Hash values are also useful for verifying the integrity of data sent through insecure channels

So technically it says it's useful if the data was sent through an insecure channel. It doesn't specify how the hash was sent. You are completely right: if the attacker can tamper with the data and you send a hash alongside it, then they can also tamper with the hash value.

So the hash has to be sent via a secure method. The useful part is that you can use this short hash value (of only a few bytes) and compare it over a secure channel to verify that your multi-gigabyte data file is correct. For example, you can talk to someone over the phone to compare the hash value (if you know the voice of the other person and trust that nobody can do voice impersonation) and thereby verify the large file.

The second citation doesn't really say anything about security, just verifying that nothing was modified, which could mean modified by transmission error.

Luc
  • 32,378
  • 8
  • 75
  • 137
1

If the hash of some data is computed and sent along w/ the data, can't an attacker alter the data, re-compute the hash and the receiver would be none the wiser?

In a data stream that is only hashed, then yes they can.

If you want to mitigate this you need to ensure that this cannot be done without detection, such as signing the hash and including the signature in a field. Then the message would be verified as not tampered with if the hash matches and the signature can be verified.

Pedro
  • 3,931
  • 12
  • 25