I very rarely see websites provide a SHA-2 hash that's signed to ensure file integrity for the user downloaded side file, and show that the file has not been manipulated or out right replaced with a malicious version, such as the incident that occured with CCleaner last year. The only recent ones I've seen provided are Jetbrains products and KeePass, and you had to scroll pretty far to find it tucked under the page.

Edit: Like the Certificate Authority, can we not have a Hash Authority which signs the hash that the company provides for their product so the issue of a server takeover would be mitigated dramatically?

  • 3
    Maybe because 'the mass' don't care at all about that, and it results that companies dont want to bother doing so... Commented May 21, 2018 at 12:46
  • I get you... but look, do you think your grand ma or even your mother, or your little brother, would care about making sure the release is the same as the original one ? certainly not :( That said, it would be a good idea to do that to make people aware of these risks, yes Commented May 21, 2018 at 12:58

5 Answers 5


They do! Many Windows executables have a built-in certificate signed by a CA trusted by Microsoft. The operating system checks this certificate before running the software. Additional configuration can be made to prevent unsigned software from running, rather than just showing a warning. Furthermore, it is possible to create even further restrictions that only allow Microsoft-signed executables to run, not just executables that are signed by a Microsoft-trusted publisher.

Linux and related operating systems do not support this yet (ELF, unlike PE32, does not support embedded certificates), but there is very little push to do so because most software installations are done using its native package manager which usually does verify the software. In this case, there is no certificate from a trusted CA. Rather, the signature is provided by the maintainers of the software repository and verified by the package manager at during installation.

For security-sensitive downloads that are necessarily not provided by package managers and cannot have embedded signatures, signed hashes are often provided. This is the case with bootable ISO images in particular, though some only provide unsigned hashes, not signed ones. Unfortunately, there are still numerous examples of executables provided over insecure connections that are unsigned simply because the website administrators do not understand the importance of integrity and underestimate the risk of compromise.

  • @Azxdreuwa No. As other answers have discussed at length, an admin posting a hash on their home page provides very little security. All the examples in this answer require a central authority, and a process for that central authority to vet the things they're signing (or the certificates they're countersigning); failing to create or belong to such an authority is not "incompetence".
    – IMSoP
    Commented May 22, 2018 at 16:11
  • @Azxdreuwa But in the absence of a central hashing authority, a self-signed hash proves no such thing. In most cases, any party able to replace the download would also be able to replace that hash, or the public key, with whatever they wanted, and most users would never know the difference. And, as I pointed out in my answer, even a trusted hash wouldn't have solved the CCleaner incident anyway.
    – IMSoP
    Commented May 22, 2018 at 16:57
  • @Azxdreuwa Yes, Microsoft are acting as the central hashing authority for certain types of software; as are Google, for Android apps; such hashes are, by definition, not "self-signed". The problem is that the majority of the admins you are branding as "incompetent" have no such authority they can get to sign their releases, or countersign their certificates, so just posting a random hash on their homepage gives a completely false sense of security.
    – IMSoP
    Commented May 22, 2018 at 17:00
  • 3
    @Azxdreuwa I think you have the cart before the horse: the problem with introducing a counter-signature on hashes is not "admins can't be bothered to hash code", it's "there isn't anybody set up to do the counter-signing". Saying people should put up self-signed hashes in the hope that some authority will come and counter-sign them is like saying that people should print their own passports at home, in the hope that their government will come along later and stamp them as official. Trust is not something that can be automated away - you've got to have some process for who you trust and why.
    – IMSoP
    Commented May 22, 2018 at 17:09
  • 1
    @Azxdreuwa As one final thought, these articles about Extended Validation website certificates are a great example of why the hard part of being a central authority is not doing the signing, but deciding what you should and shouldn't sign: scotthelme.co.uk/… scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca
    – IMSoP
    Commented May 22, 2018 at 17:28

You mention CCleaner, so it is relevant to link to Would a digital signature have prevented the CCleaner compromise? The short answer is that it would not have prevented this particular compromise.

This gives us our first problem with providing hashes: Who are we trusting to sign the build, and what are we trusting them to check? Does the signature simply represent the official build server, which could be compromised? Or does it represent an actual security audit by some pre-trusted party?

However, there are other attacks that such a hash would guard against - for instance, a compromised or fraudulent mirror offering a tampered build. In this case, it would be enough for the primary project page to publish a hash, which could be verified against the download offered by any mirror.

However, this leads us to the second problem, which is one of the hard problems of cryptography: key distribution (or, in this case, signature distribution).

For an unsigned hash, you are simply trusting the page that displays that hash not to have been tampered with. A signed hash at first sight seems better, but you still have to download the public key from somewhere, so you are still trusting the source of that key. If an attacker can direct a user to a fake download page, they can add a link to a public key of their choosing, and the user will get a false sense of security by verifying the hash of a compromised download.

The alternative is to have some central authority that you trust for multiple different applications - this is the principle behind Windows driver signing, Linux package managers, and phone app stores (and also behind the certificates used for HTTPS websites). Now you have a new problem: why do you trust those central authorities? Are they directly auditing the source code and build processes of the files you're downloading? Or are they delegating the trust, via a counter-signed certificate, based on some assurance from the party actually producing the software? Plus, you still need to acquire the root public key somehow - presumably it was included in some trusted installation media when you installed the OS / app store / package manager.

In the end, publishing a hash will be most useful for large projects, where:

  • the same user is likely to download and verify multiple versions, or different applications, with the same public key;
  • and, the source of the public key is likely to be different from the server offering the download (a different server, or some physical medium)

But even then, it cannot fix all exploits, as CCleaner demonstrated; and there is a danger in giving users a false sense of security.


Because most users won't check the hash anyway.

It would take a common download protocol that automates and enforces signature verification for this to actually make a dent in malware spread.

That still wouldn't be perfect - a hacked server could also post a different hash. Signing the software itself, as with Windows drivers, probably has more potential for making an impact. Both could be done as well.

  • We could. But when you have a solid and agreed-upon CA (the main issue with PKI), it's more straightforward to sign the software file itself, rather than its separately posted hash.
    – Therac
    Commented May 21, 2018 at 13:07
  • We should be using a common protocol in which sites provide a separate hash to their software for validation. Security Professionals need to stop blaming people for poor security when it within out power to implement changes that impact them positively without them noticing. Commented May 21, 2018 at 16:18
  • I agree. I just think signing the software itself would be an even more effective step, but it has obvious limitations too.
    – Therac
    Commented May 21, 2018 at 17:06
  • 1
    I would have thought the distinction between "signing a hash" and "signing the software itself" is a bit of an arbitrary one: don't most algorithms for signing a large piece of data start by hashing it, and then signing that hash?
    – IMSoP
    Commented May 21, 2018 at 17:28
  • The hash is signed either way; the difference is that embedding the signature in the software keeps verification independent of the download source. I.e. it will work even if the software comes from a thumbdrive, gets DL'ed by an outdated browser, etc. Changing one OS function in a way that's been done seems more straightforward than blocking each individual point of entry.
    – Therac
    Commented May 21, 2018 at 17:50

I am seeing more hash (commonly md5) being shown on site related to linux. Mainly, when iso are provided.

You don't want to install an OS from a corrupted ISO, do you ?

You'll find the hash also of the Windows 10 ISO too, on the download page.

The hash is used here only to check the integrety of the downloaded file(s).

When you need to check that the file has not been tampered with, serious site, provide a GPG key signature that you need to check with a GPG key. For example, tails.boum.org does that.


Because it's almost pointless form a security perspective. Hashes next to downloads are a one-stop-shop for compromises; the attacker updates the hash in the exact same place as the download is linked. The download need not even be replaced, it can be linked to a third party site since the user-facing html is what's under attack.

It's some comfort if a 3rd-party site hosts the hash, but it's been a long time since I've seen that implemented and even then, it just means two sites need compromised instead of one. If the hash is next to the file in an FTP folder, how hard is it to replace both, considering they have the same perms? Unless one is a hardened target off-site, what's to make it any safer than just the link-offering page/folder?

The idea of validating download hashes is good, it's just not easy to get the hash to the user in a manner any more trusted than the link itself. They are still good for integrity, just not authentication on a single-authority basis. A central authority would be nice, but afaik, there's not one yet.

  • OP explicitly mentioned signed hashes, not plain hashes.
    – forest
    Commented May 22, 2018 at 4:19
  • @forest: given the title and edit-added info, it's not entirely clear what is meant by that, without an example of such a download page. My point is that without a central authority, hashes and even signatures are only as trustworthy as the origin. that's an important consideration and if it cost me a few -2s to get that out there, so be it.
    – dandavis
    Commented May 22, 2018 at 5:09
  • The original post (pre-edit) contained a SHA-2 hash that's signed.
    – forest
    Commented May 22, 2018 at 5:10

You must log in to answer this question.