
Show HN: Hash Archive helps you verify the hashes of insecure downloads - btrask
https://hash-archive.org/
======
geofft
PowerShell 4.0, shipped with Windows 8 and above, has a pretty simple Get-
FileHash command built in, so you don't need a separate download on those
platforms. (On Windows 7 you still need either the download you link to, or a
manual upgrade to PowerShell 4.0.)

[https://technet.microsoft.com/en-
us/library/dn520872.aspx](https://technet.microsoft.com/en-
us/library/dn520872.aspx)

I believe the syntax is just

    
    
        Get-FileHash [file] -Algorithm SHA256

~~~
btrask
Thanks, I've made a note to add this to the FAQ.

~~~
zokier
For previous versions of Windows there is certutil included which can used to
compute SHA1 with -hashfile option:

[https://technet.microsoft.com/en-
us/library/cc732443%28v=ws....](https://technet.microsoft.com/en-
us/library/cc732443%28v=ws.11%29.aspx#BKMK_hashfile)

------
tekacs
The author's other project,
[https://github.com/btrask/stronglink](https://github.com/btrask/stronglink)
looks fairly interesting too - 'A searchable, syncable, content-addressable
notetaking system'.

~~~
btrask
Thanks! Right now we're sort of in a chicken-and-egg situation where
everything uses (mutable) URLs, so knowing the hash of a file isn't very
useful. The Hash Archive is part of my strategy for promoting content
addressing, to hopefully raise demand for systems like StrongLink (and
others).

~~~
tekacs
The more people pushing for awareness the better! Hopefully with other work
like IPFS (which you do reference), use of this approach for /more/ consumer
systems is around the corner. :)

~~~
btrask
Yeah, IPFS is a big one. I plan on adding support for computing IPFS hashes to
Hash Archive at some point too.

------
amjo324
Great idea for a project. Nice job.

It says in the About section on the home page "Unless someone can intercept
your local traffic and our traffic to a site, you'll be able to spot MITM
attacks". I'd argue that this is not entirely true. If an attacker operating
as a MITM can intercept all local traffic (e.g. via some form of DNS attack),
they do not need to control the traffic from hash-archive.org to 3rd party
sites. They simply need to control how hash-archive.org is presented to the
victim. In theory, the attacker could serve up a bogus version of hash-
archive.org that appears to be legitimate but is returning falsified hashes
that match the malicious downloads they have intercepted elsewhere.

You might claim this is not possible because hash-archive.org runs over HTTPS
so an attacker would also have to somehow generate a valid SSL certificate
signed by a trusted CA. This is true but if someone types hash-archive.org
into their browser URL bar, the initial request is made over HTTP. The
legitimate hash-archive.org redirects the client to HTTPS seamlessly but a
fraudulent hash-archive.org could just keep the victim on HTTP.

To provide some mitigation against this type of attack, you could do a couple
things:

* Only allow hash-archive.org to be accessed over HTTPS (port 443). Close port 80. [EDIT: in fact, this doesn't really help all that much because the MITM can still try serve their bogus version of hash-archive.org over HTTP]

* Set the HTTP Strict Transport Security header (HSTS) [1]. After the first visit to the legitimate hash-archive.org, compliant browsers will only ever allow future visits to be made over HTTPS.

For good measure, you could also set up HTTP Public Key Pinning (HPKP). HPKP
is a 'security feature that tells a web client to associate a specific
cryptographic public key with a certain web server to prevent MITM attacks
with forged certificates.' [2]

[1] [https://developer.mozilla.org/en-
US/docs/Web/Security/HTTP_s...](https://developer.mozilla.org/en-
US/docs/Web/Security/HTTP_strict_transport_security)

[2]
[https://developer.mozilla.org/en/docs/Web/Security/Public_Ke...](https://developer.mozilla.org/en/docs/Web/Security/Public_Key_Pinning)

~~~
kefka
HPKP is also the technique used/abused by Microsoft to keep users from knowing
what the Windows 10 system is telling to other servers about us.

~~~
userbinator
Security is a double-edged sword.

------
sprin
Fantastic! While not as bulletproof as receiving the hash out-of-band for a
critical resource, this is better than verifying against a hash received from
the same origin as the resource, and far better than no hash verification at
all. And because this is FOSS, we can be gain some protection against the
compromise or MITM of a single, central hash-archive server when many of them
are deployed by distinct entities on different public domains.

One request: there are lots of users who would be well-served by a way to
compute hashes in-browser via the WebCryptoAPI [1]. Would you consider
accepting this feature into hash-archive? For users who aren't able to install
or have difficulty using a hash calculator locally, this would enable
verification of downloaded files in a one-stop online workflow.

[1] [https://www.w3.org/TR/WebCryptoAPI/](https://www.w3.org/TR/WebCryptoAPI/)

edit: I stood up an instance here, and I'll make an effort to keep it running
and updated: [https://hash-archive.probablybroken.com/](https://hash-
archive.probablybroken.com/)

------
ikeboy
Pretty cool. Could this be made into a browser extension that alerts you if
there's a difference?

~~~
btrask
Yes, this has been discussed. It has to be done carefully so that it doesn't
leak every URL you download, but if done well I think it would be useful.

~~~
ikeboy
Double hash the url and check if it's in the database: if not, prompt the user
if you want to upload the actual url.

~~~
btrask
I believe that double-hashing is "equivalent" to single-hashing. See this
issue: [https://github.com/ipfs/refs-denylists-
dmca/issues/2](https://github.com/ipfs/refs-denylists-dmca/issues/2)

There are some ways of doing it, depending on exactly what your threat model
is, but I think it's risky in general. Right now this is just in the planning
stages, but I want to have submitting URLs be a manual button click for each
download, and also provide an option to use a local copy of the database (so
that all lookups would be completely private).

------
Buge
It would be nice if there was an easy way to copy the hashes for example to
diff it against what you computed. As it is now, the page is laid out so that
it is hard to copy just the hash.

~~~
btrask
Agreed. I've thought about adding a JS/Flash clipboard button. For now, if you
click a hash, it's easier to copy from the hash's own page.

I think there's also potential for better tooling, for example CLI tools that
integrate with Hash Archive (or other sites/databases) directly.

~~~
kpcyrd

      sha256sum -c <(curl -sS https://hash-archive.org/history/http://openwall.com/signatures/openwall-signatures.asc | sed -nr 's/.*sha256&#x2F;([a-f0-9]*).*/\1 openwall-signatures.asc/ p')

