Even a slower or more "secure" hash wouldn't help much, because I can take your starting known email address and find comments you have made. i.e. I can start with "bill@example.com", slowly hash that to 901e54d1 and then search google for 901e54d1 to find comments you've made.
Speed isn't a big deal if I'm interested in attacking specific subsets of emails. (Which could still be a "large" set in a real world sense.)
As long as the hashing algorithm is known then it would be weak to finding comments made by known authors. If the hashing algorithm is unknown then it falls under security by obscurity.
So is there any way to implement a decentralised pseudonymous but ID-based system where the ID is tied to email but cannot be generated from email (or rather is generated from email but with some added entropy that prevents going in either direction in the future.).
It's possible to prevent this. Disquis could create a service limited to their network that could store a unique id for each registered email address and hashed with the email, or used instead of the hash. This obviously adds additional computation, latency and storage to their system though so it's far from free but it is definitely possible to prevent this type of hash lookup.
you could salt the hash twice. One (large) you store the other you throw away. This way to compromise a specific account you would have to steal it's stored hash. If there was a leak of the hashes you would need to bruteforce all the hashes which were thrown away
In general, what you're asking about is called a "salted hash". I don't understand enough about Disqus's system to say it would definitely have prevented this vulnerability.
A salted hash only slows down brute-force attacks and dictionary attacks. The salt is still stored with the hash, so you could still eventually match the email address with the hash. Instead of hashing each email address once and comparing it with all of your collected hashes, you'd have to hash each email address using every salt until you found a match.
Sure since they're using MD5 then a salt wouldn't solve their problem, especially if the salt were also part of the url. And let's not pretend that the url itself is somehow secret: there are many ways to collect those, particularly if specific users are targeted. Usually when people are this boneheaded about hashes they're trying to save storage space, but I can't imagine that storing a separate random identifier would add significantly to Disqus's storage.
I think encryption would be the correct way, since you don't want people to be able to compute either plaintext from ciphertext or ciphertext from plaintext.
You would still have to provide an encryption oracle, which would allow bruteforcing, but that could be rate limited.
Even a slower or more "secure" hash wouldn't help much, because I can take your starting known email address and find comments you have made. i.e. I can start with "bill@example.com", slowly hash that to 901e54d1 and then search google for 901e54d1 to find comments you've made.
Speed isn't a big deal if I'm interested in attacking specific subsets of emails. (Which could still be a "large" set in a real world sense.)
As long as the hashing algorithm is known then it would be weak to finding comments made by known authors. If the hashing algorithm is unknown then it falls under security by obscurity.
So is there any way to implement a decentralised pseudonymous but ID-based system where the ID is tied to email but cannot be generated from email (or rather is generated from email but with some added entropy that prevents going in either direction in the future.).