Force HTTPS on forum registration page?

[timpattinson]

Hi all,
Upon registering today I nearly typed my password into a an unsecured, HTTP site.
Yeah, should have been more careful, but this isn't great security practice.

Manually typing https into the url bar appears to have fixed the problem.
Screenshots for reference: https://imgur.com/a/pxJMd

[ataradov]

Who cares about your EEVBlog password?

[Brumby]

The EEVblog forum has been set up to run either HTTP or HTTPS - just depends on what you want to do.

Want HTTPS?  Just change the URL to HTTPS and you'll stay with that.

[ataradov]

Everyone should. Especially is as is common practice the password is used for multiple sites. Not judging. Just saying.

I use a password manager, so all my passwords are long and unique.

But realistically, who would want to intercept this stuff. It is a pretty low value target.

[Ian.M]

There are good reason *NOT* to force everyone to use the https protocol - it will exclude many potential users in 3rd world countries who cannot afford a recent PC that can run browsers with current encryption, existing users with legacy hardware and some users who are behind restrictive firewalls or proxies.

See https://www.eevblog.com/forum/chat/ssltls-time-to-update-your-http-server/

However, even though the onus should be on *YOU* the user to maintain your own security and privacy with care, there is a strong argument for adding a big red warning message on the login and registration pages if they are being served via HTTP,  offering a link to them served via HTTPS.   

[Ian.M]

[ChunkyPastaSauce]

imo, server default should be https for stuff like passwords. One can of course provide backup methods to allow for http access, such as a simple link, but should require user action to do so.

[Ian.M]

The problem is: That simple link to a backup HTTP login or registration page can't be on a HTTPS page, or it would be as much <expletive> use as a bicycle is to a fish!

Unlike your typical social media site, this forum has to presume there is actually a somewhat functional brain in between most users' keyboards and chairs, so is it *SO* unreasonable to expect users to take a >tiny< bit of responsibility for their own security?

Anyway the current pressure towards HTTPS is *all* security theatre smoke and mirrors from the big browser companies and orgs and their advertising partners (who hate the idea that their paid for advertising  could be replaced by someone else's in transit), as we are all habitually receiving HTTPS pages delivered over CDNs without guaranteed end to end security, around 75% of the world user base of the WWW as a whole, doesn't use ad-blockers (and advertising CDNs are even easier to compromise) and 99%+ happily allow Javascript to run by default on all pages they visit.

I suggest reading the link I posted, which has further links to the great EEVblog HTTPS debate of 2017.   The horse isn't merely "pining for the fjords", its positively skeletal.

[ChunkyPastaSauce]

Everyone should. Especially is as is common practice the password is used for multiple sites. Not judging. Just saying.

But realistically, who would want to intercept this stuff. It is a pretty low value target.

People collecting passwords from people who work in engineering/research industries and just the general account skimming that goes on to be compiled, sold as bulk account lists.

The problem is: That simple link to a backup HTTP login or registration page can't be on a HTTPS page, or it would be as much <expletive> use as a bicycle is to a fish!
....
I suggest reading the link I posted, which has further links to the great EEVblog HTTPS debate of 2017.   The horse isn't merely "pining for the fjords", its positively skeletal.

I read the link; it discusses forcing https as a requirement, rather than giving preference to use of https.

To have the server default to https with http fallback, the http login entry page contains a https element the user does not see. If successful, then the client supports https and redirects to the https login page. If the element was not successful, then the client does not accept https; a link offering a non secure http login is offered. This automatically defaults to https logins if the client supports it, and requires user acknowledgement if not.

Another way is to have the https and http login entry serve slight different pages. While the https version is the normal enter info and go..the http password page has one additional user interaction requirement (checkbox) acknowledging non-secure password transmission and offers a link to the https. Although https isn't automatically default, it's simple in implementation and still requires user acknowledgement in the http case.