[dpkonofa]

Yes, I do. I linked to that very same site. The prefix is the only thing that’s sent and the hashes are computed as unique for each combination of URL. The docs explicitly say that http://evil.com/foo is unique from http://evil.com/foo?bar.

[rocqua]

So any secrets communicated in the URL via e.g. get parameters can be potentially brute-forced based on the hash?

[amdavidson]

If you have the computing power to brute force sha256 then there are few security precautions a user can take against you.

That opens up forging SSL certificates, signing Debian packages, and a whole slew of other things that you could pull off with more computing power than has existed in the whole of the universe.

Context: https://bitcoin.stackexchange.com/a/41842

[rocqua]

Suppose a public PGP key is communicated in the URL.

I don't think there are enough PGP keys in the world that simply trying those keys in a certain prioritized order wouldn't find a lot of keys.

This way you could recognize who someone is talking to based solely on their 'malicious browsing' send hashes.

In general, anytime you know a secret in the URL comes from a low (min-) entropy distribution you can use the truncated SHA-hash as an oracle to (approximately) figure out the secret. Obviously, if the secret is a 128 bit session cookie, you won't find that by brute forcing. Heck, in that case your 32 or 48 bits of hash prefix won't even be enough to uniquely identify the session cookie.

When you get to a 64 bit secret (say again a session cookie), with a 48 bit prefix, things already get dicey. It seems possible that some state actors can already brute force 64 bit secrets, and with a 48 bit prefix, you'd get about 2^16 ~ 64000 (more, but dont wanna compute exactly) candidate session cookies. Those can actually be tried at the website to see if they work.

[nebulous1]

You're assuming the range of possible parameters is very large. This might not be the case.