| Reference | Downloads | Github

Enable TLS encryption

Currently the forum is only available via HTTP; there is no encryption layer involved. We should (read: must) switch to HTTPS, at least for the login portion. To my understanding, login credentials are currently transferred in plain text, which is a massive security problem for those logging in with username and password, and shouldn’t happen in 2016.

Any ideas where to best get a certificate?

<TL;DR> @discourse could we have SSL/https turned on please? Is there anything we need to do to configure it?

I think this needs to be enabled by the @discourse team on the server. They’re kindly providing us with free hosting, including maintenance and backup, and I think https is normally a premium (paid-for) option. Oh, wait. No, I just looked back at the blog post
and it says that SSL support is indeed permitted for open-source hosted community projects (like ours).

I think we just need to say “pretty please”! :slight_smile:

1 Like

Sure Falco from our team can enable it for you tommorrow.

1 Like

Awesome, thank you!! :smile: is already up and running!

Before we can enforce HTTPS for everyone (HSTS) we need a few things:

  • Change redirect_uri on Social Logins to work with the https version (Google and Github)

  • You Facebook login is broken because the app is still test mode, but probably need the https redirect url too.


1 Like

Thanks Falco!

Am I correct in assuming that all login credentials for username/password-based logins used so far, or at least the sessions established via username/password authentication (and therefore the associated accounts) have to be considered as potentially compromised? (OAuth-based logins would obviously not be affected) Even the JS the client executes could have been manipulated by a MITM.

Cool. Thanks @Falco

I’ve updated the uris for the google, github and facebook apps and made the facebook app live. All seems to be working correctly from a quick check.

1 Like

HSTS is enabled now.

Yes. If using local password and username you can change passwords now.

Great, thank you!

I am very, very concerned and consider this an extremely serious issue. Users are known to implement suboptimal security strategies, such as sharing passwords between accounts and computers. I don’t want to blame anyone, but it is clear that password-based authentication should have never been available over an insecure connection in the first place. This is a security nightmare and must not be taken lightly. I, for example, regularly access the forum from insecure (public) WiFi networks. I am very glad I have always authenticated via OAuth, otherwise the credentials and/or session tokens would have been out in the public.

Shit has clearly hit the fan here.

We must issue a statement to our users urging them to change their password

  • on the forum (but see below)
  • on all internet and network accounts
  • on all computers

where they use(d) the same or similar* credentials/password.

This must happen as soon as possible.

*Some users reuse passwords all over the place, and simply append a website or service name, for instance, basepassword-psychopy.

Further I suggest:

  • all existing sessions (from password-based authentication) be invalidated ASAP
  • all passwords of users who have authenticated via username/password in the past be reset ASAP. This would of course make point 1 of the previous list (manually change password on the forum) kind of redundant / alter the procedure a bit.

I’m currently deeply worried.

Sorry if I didn’t made myself clear, English isn’t my first language.

The forum was running on http, and we enabled https as soon as possible when requested. Now it’s running with https only to make it as secure as possible.

About the theoretical compromise of passwords and escalation in case of bad security practices, yes it can happen. In my experience almost everyone will use social logins when possible, but this will vary between audiences.

Richard, although I understand your concerns and I agree we should post to make people aware of the potential issue, I don’t think there’s any need to be deeply worried. There’s no sign of anything bad having happened as far as I’m aware.

Most people would have been unaffected:

  • logging on using google or github, rather than your password, would be fine
  • re-opening your browser, with its stored cookie so you don’t have to log on, would be fine
  • from a secure network (e.g. work, home, anything with an enterprise WPA password) logging on to a non-secure site would not be very risky
  • even logging on while at your local starbucks, and typing in your password, my guess it that it’s still relatively unlikely to be eavesdropped. I would really avoid it if I could, but I expect it’s rarely an issue. Basically, I imagine most wifi hotspots don’t have anyone going to the effort of eavesdropping or operating MITM servers

I agree we should put up a post advising people of what this all means and recommending that people change their password if they might have been affected, but I doubt it has been a major issue for anyone.