The situation is very similar to password storage, where you want to not make it trivial to brute-force moderate-entropy passwords even if your database gets breached. We have functions designed specifically for that: scrypt, argon2 etc. https://www.npmjs.com/package/scryptsy is a pure JS implementation of scrypt for example.
Even with scrypt the situation is not great, but using sha for this kind of thing is no longer state of the art. If people are willing to (a) download and run a program rather than rely on the browser and (b) willing to wait half a minute or so for the result then you could easily tune the scrypt/argon parameters up to 11 but at the cost of quite a bit in the way of usability. If "must work on smartphones without extra app downloads" is a requirement you're pretty limited in what you can do this way.
Another solution might be to use real servers but host them on the "dark web" - get Tor a bit of publicity in Catalunya!
EDIT: in response to a few posts that briefly appeared and then disappeared again - IPFS is fine. SHA256 for authenticating a page is fine. I'm only objecting to using raw SHA-anything as a key derivation function as in the section "A static database".
I'm not sure what you mean by "the crypto is not ideal"? I was under the impression that there are not yet collisions for
SHA-256 https://github.com/ipfs/faq/issues/22
The attack mentioned on the page is brute-forcing someone's details from partial information:
"it can be used to “fill the gaps” of information about any citizen. If you know someone’s birth date and the area where they live, you can obtain their government ID by trial-and-error on that website."
The mitigation is slowing down the number of guesses/second that an attacker can try. In a well-designed key derivation function, an attacker with 100x the resources should only be able to try out guesses 100x as fast. That's what scrypt/argon2/bcrypt/PBKDF2/... try and achieve.
SHA and other general-purpose hash functions tend to be easy to parallelize, at least in parts, and you can get huge speedups on GPUs or even better, FPGAs/ASICs. That's why no-one serious still mines bitcoins on CPUs and the big mining syndicates [hire planes](http://uk.businessinsider.com/cryptocurrency-miners-rent-boe...) to ship GPUs a little bit faster.
This has nothing to do with collisions. It's to do with hash functions being designed to be fast, and key derivation functions are designed to be slow and memory-hard.
I downloaded the Bitcoin mining app in 2010, opened it once, got bored of waiting for it to sync with some server, then shut and forgot about it for a few years. It might be a funny story to tell my grandkids if BTC is still around
Yup. For one example of a software package that can use GPUs to accelerate password cracking and hash brute forcing, folks can look at hashcat: https://hashcat.net/hashcat/
Scrypt is tweakable for RAM and runtime constraints. From that PBKDF, it would make sense to use something like HMAC-SHA2 with another magic nonce, and then private information plus previous PBKDF output hash together as the authenticated part. If you want to get really tricky, add another random secret hash.
And, they probably should’ve used HMAC-SHA2 to derive the public primary index key insead of a hash function directly.
The situation is very similar to password storage, where you want to not make it trivial to brute-force moderate-entropy passwords even if your database gets breached. We have functions designed specifically for that: scrypt, argon2 etc. https://www.npmjs.com/package/scryptsy is a pure JS implementation of scrypt for example.
Even with scrypt the situation is not great, but using sha for this kind of thing is no longer state of the art. If people are willing to (a) download and run a program rather than rely on the browser and (b) willing to wait half a minute or so for the result then you could easily tune the scrypt/argon parameters up to 11 but at the cost of quite a bit in the way of usability. If "must work on smartphones without extra app downloads" is a requirement you're pretty limited in what you can do this way.
Another solution might be to use real servers but host them on the "dark web" - get Tor a bit of publicity in Catalunya!
EDIT: in response to a few posts that briefly appeared and then disappeared again - IPFS is fine. SHA256 for authenticating a page is fine. I'm only objecting to using raw SHA-anything as a key derivation function as in the section "A static database".