This is an addition to @TopherBrink's answer, with which I agree greatly. First of all yes, use HTTPS and HSTS, and do have things behind a login screen. Second, we need to see some ethics:
Ethical discussion
This is the internet, all content is there, if someone wants it he will get it. It may be blocked by firewalls, and someone will find a hole puncher or use a proxy/VPN, it may be DNS filtered and someone will make a website of IPs to use.
If the content is dangerous there are humongous risks in several countries: prison, torture, death penalty. But against those risks you have pretty much two options:
Don't do it and allow someone else to serve the content to these people. There will be someone else, this is the internet.
Do a best effort on deniability. I disregard deniability as poor security, but you do not really have options.
And I did see teenagers being able to use a VPN based on tutorials found on the internet. The problem is that, although their configuration worked, it was leaking a good deal of info. In general if you do not serve the content someone else will, even if the content needs proxies/VPNs to access.
The ethical cause is more complex than don't serve it and don't be indirectly responsible for someones death. If you give up on serving the content you are still responsible for someones death if he was caught by accessing content from a place that was worse secured than what you could do.
Escaping responsibility is not an ethical point. Therefore I'll defend the least popular option and argue to do it. But make the best effort you can on deniability.
Final ethical note
Always remember that some users are just stupid, and therefore there is no way of protecting them. If you cannot deal with the fact that at some point or another you will need to sacrifice one for the good of many, then don't do it. But don't do it for that reason. Not simply because it is dangerous.
Deniability proposal (i.e. one way to do it)
The biggest issue is that you need to find a way to give logins to trusted users and not give them to not trusted ones. One way to go around that it to have two websites, let's say: safewebsite.com and secretwebsite.com.
(Both domains running only over HTTPS, and implementing HSTS)
safewbsite.com will contain safe content, will be accessible without a login by default but users will be able to register.
secretwebsite.com will always return the same "safe" page for anyone. The only way to get the rest of the content is to be authorized, i.e. be a registers user of secretwebsite.com. Now, there is no way to register on secretwebsite.com (it returns only a single page). The only way for secretwebsite.com to give you the correct token (let's say a httpsonly cookie for simplicity) is by issuing a GET to the correct URL. Say https://secretwebsite.com/logon/6733abf78..77bab99 (or base64 encoded, whatever). That URL is your session token.
(using GET for authentication is bad, but since we are on HTTPS and the URL is a proper, difficult to guess, token it is acceptable).
The token must be difficult to brute-force. And the only way to get a correct token (a correct link to secretwebsite.com) is from safewebsite.com.
Now, you can choose (literally cherrypick) users from safewebsite.com who can access secretwebsite.com.
The merit of this approach is that you create a triage area (the safe website) from which you can choose users that will be responsible enough to access the secret website. If you construct the session mechanism correctly, you can give and take the ability to access the secret website from your users.
The problem is that this will work only for a small number of users, and is susceptible to social engineering against you. Making and algorithm to evaluate truthfulness of a user is no trivial matter (if at all possible), therefore there is no way of automating the user selection. Another issue is that you need to prevent safewebsite.com from becoming a discussion ground about how to access sectretwebsite.com, since then you completely lose control about who is trusted and who isn't.
Security summary
Good points:
secretwebsite.com does not exist, OK? No, it does not, it is always "under construction". The fact that someone saw something in there is a creation of his own mind.- You can take out logins of problematic users. Or better, you need to take them out. If a user openly talks about
secretwebsite.com on safewebsite.com he is doing more harm to both websites than good.
- You give deniability to yourself and your users. To make it a little more plausible you can randomize the size of the (fake) page sent from
secretwebsite.com (so arguing that someone gets a page of different size is not viable).
- There is also a point of confusion. Since no one knows how to actually access
secretwebsite.com (the URL appears to certain users and doesn't to others based on your whim, which cannot be quantized), you can shutdown secretwebsite.com temporarily in dangerous times.
Bad points:
- Deniability does not work against an attacker that wants to do something to you just because he needs to do something to someone (namely, he needs a scapegoat). Deniability will never prevent anyone from being a scapegoat, but neither will any other security measure if the attacker has physical and judicial power over you.
- You will need to deal with urban legends about
secretwebsite.com. It is important that you do not allow them to roam free on safewebsite.com, otherwise you will have a visible correlation.
- Deniability works because in modern society suspicion is never the same as proof (i.e.
suspicion != proof). The moment an attacker can rely on his suspicion to sentence someone, he can do it at his own whim. The good side, is that such an attacker may be suspicious of anyone, and going through website loops is a lot of work compared to catching someone random on the street.
- It is a lot of work. If the community of your users grow you will need very ethical moderation, which is difficult to find.
Extra notes:
- Is it dangerous? Yes, people may get caught. But they would be scapegoats anyway. An authoritarian regime needs scapegoats, you need to make sure your users are harder to make into scapegoats than others.
- You said a lot, but would such a website work in the real world? Yes, it works. Once upon a time I helped setting up one such website. It was 5 years ago, and the website is still alive. Both the safe and secret sides.
- Can you tell us which website it is? No, read above for the reasons why.
