Registration Page is Not Secure

[sadams101]

I reported to IPS that their registration page (/ips/registration/) is not a secure page, even if I have selected my login and admin areas to be https in the board settings. I think we can all agree that this is a HUGE bug--you can't ask for personal data via a non-secure page.

My site's rankings have dropped recently due to this, and I received warning from Google about it.

"Beginning in January 2017, Chrome (version 56 and later) will mark pages that collect passwords or credit card details as 'Not Secure' unless the pages are served over HTTPS. "

Remarkably Marc Stridgen at IPS told me "The login over https would cover the login pages only, and not the registration page. In order to have the registration page over https, you would need to switch the site over to https as a whole. "

Thank you, but I don't want a complete domain change, which google warns could drop my ranking for weeks, to fix what is really just bad coding. This is a bug that IPS needs to fix, and if affects everyone reading this whose entire site is not in https (the vast majority of you).

I have tried simple server 301 redirects which don't work, and create a redirect loop, so I can't fix this on the server level. The only way is for IPS to fix their bug, and code this page properly.

[Day_]

It's not a bug if it's working as intended which it is. 

I changed my site over to https:// with no drop in rankings, I even reverted back 2 months later with no drop as well as changing from .co.uk to .uk

Use a htaccess permanent redirect.

 

[opentype]

3 hours ago, sadams101 said:

Thank you, but I don't want a complete domain change, which google warns could drop my ranking for weeks …

Do you happen to have a link where Google states that?

[sadams101]

You are incorrect about it not being a bug. Simply search google as to whether registration pages that ask for personal data should be https or not--the admin switch for making the admin area and the login page https should also include the registration page--why wouldn't it?

Daveoh, please give me one good reason why that page should not be HTTPS--on the registration page I am asking members for their password and login on an insecure page. I am also asking them for their name, address, phone, etc., but really, any google search will tell you not to EVER ask for a login and password on a non-secure page. Therefore, the https switch in admin has a bug. I invite anyone who reads this to convince me otherwise--no offense Daveoh, but you haven't.

I've been on the internet over 20 years (Celiac.com, but the forum is  www.celiac.com/gluten-free/ )  with my site, and my forum has more posts than this one...I know a bit about securing sites, SEO, etc. 

Below is the entire email I received from Google Search Console Team.

One other major problem I've had with IPS, and I now also consider it a bug due to the fact that it causes all uses of IPS to lose page rank in google, is the fact that IPS doesn't combine Javascripts or do other obvious things to increase site speed. I noticed they are now blocking google's site speed check for this site:

https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Finvisionpower.com%2Fforums%2Ftopic%2F434738-registration-page-is-not-secure%2F&tab=mobile

I am not sure why they would do this, but I used to use this to complain about this very issue. This site, like mine and all of your sites, is likely scoring lower now due to not fixing these issues--it affects all IPS users' page rank. Sites that ignore these things were hit especially hard a few months back by the Possum Update:

http://www.clickthrough-marketing.com/seo-news-roundup-googles-possum-update-has-effect-on-local-serps/

Why would IPS ignore google site speed recommendations for so many years--why not just include such optimizations into development? Only IPS knows, right?

 

Quote

Nonsecure Collection of Passwords will trigger warnings in Chrome 56 for http://www.celiac.com

To: owner of http://www.celiac.com

Beginning in January 2017, Chrome (version 56 and later) will mark pages that collect passwords or credit card details as “Not Secure†unless the pages are served over HTTPS. 

The following URLs include input fields for passwords or credit card details that will trigger the new Chrome warning. Review these examples to see where these warnings will appear, and so you can take action to help protect users’ data. The list is not exhaustive. 

http://www.celiac.com/gluten-free/topic/112719-make-up/

http://www.celiac.com/gluten-free/profile/72247-beckism/

http://www.celiac.com/gluten-free/topic/14985-narcolepsy/

http://www.celiac.com/gluten-free/topic/28100-cider-on-tap/

http://www.celiac.com/gluten-free/topic/8219-7-11-slurpees/

The new warning is the first stage of a long-term plan to mark all pages served over the non-encrypted HTTP protocol as “Not Secureâ€. 

Here’s how to fix this problem:
Use HTTPS pages to collect sensitive information 

To prevent the “Not Secure†notification from appearing when Chrome users visit your site, move collection of password and credit card input fields to pages served using the HTTPS protocol. 
 Read the WebFundamentals article  

Need more help?
• Learn more about this change in the blog post “Moving Towards a More Secure Web.† 
• Learn how to Secure your site with HTTPS.  
• Ask questions in our forum for more help - mention message type [WNC-10026400].  
 

 

[sadams101]

opentype, please see: 

https://support.google.com/webmasters/answer/6073543?hl=en

• You may experience a temporary fluctuation in site ranking during the move. With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site. As a general rule, a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer. The speed at which Googlebot and our systems discover and process moved URLs largely depends on the number of URLs and your server speed. Submitting a sitemap can help make the discovery process quicker, and it's fine to move your site in sections.

Since my site is huge, nearly 1 million posts, this could take weeks to sort out in google search, which is what happened last time I did a change.

[opentype]

1 hour ago, sadams101 said:

You are incorrect about it not being a bug.

No, he isn’t. We should create a FAQ page somewhere here to not have this discussion over and over again. Daveoh was talking about definition of the word bug and he gave the definition. That’s all. What you say is a feature request, not a bug report, since IPS hasn’t accidentally made the registration page this way and you just told them. 

28 minutes ago, sadams101 said:

opentype, please see: 

https://support.google.com/webmasters/answer/6073543?hl=en

Thanks. They keep it rather vague. I moved one of my sites over to https this year and didn’t saw any ranking “fluctuations". The pages in the index appeared as before and slowly moved over to https links, as described in the article. That being said, I support your feature request. The option to make just logins secure, should include the registration page. 

Unfortunately, this topic was not posted in the Feedback forums. 

[sadams101]

Wait until hundreds of IPS clients start getting the insecure page warnings in Chrome that will happen on EVERY page that links to the registration page (starting January 1st...2 in days!)--gee I think that is all pages, no? Then we can talk about whether or not "IPS" treats it as a bug or a "feature request." Bet it will be fixed faster than most bugs are... :-)

If the developers actually understood site security this never would have happened, but apparently, like site speed, the don't.

 

[opentype]

2 minutes ago, sadams101 said:

Then we can talk about whether or not "IPS" treats it as a bug or a "feature request."

No, we don’t need to talk about it then, because that won’t change the definition of those words/phrases. 

[sadams101]

Ok, so I turn on the https feature in admin, I assume to protect my login and password, but that feature does not protect any of my user's logins or passwords--and this is not a bug, but I should fill out a feature request. At the very least this would be poor, irresponsible software development, at worst a lawsuit waiting to happen should any of my users get their accounts hacked and money stolen from them because a hacker picked up their info. 

opentype, you should consider applying for a job at IPS as you sound a lot like Marc Stridgen after I reported this issue to him in a support ticket.

[Joel R]

20 minutes ago, sadams101 said:

Ok, so I turn on the https feature in admin, I assume to protect my login and password, but that feature does not protect any of my user's logins or passwords--and this is not a bug, but I should fill out a feature request. At the very least this would be poor, irresponsible software development, at worst a lawsuit waiting to happen should any of my users get their accounts hacked and money stolen from them because a hacker picked up their info. 

opentype, you should consider applying for a job at IPS as you sound a lot like Marc Stridgen after I reported this issue to him in a support ticket.

1.  Post this in Product Feedback.  Otherwise, IPS will never see this topic.  

2.  I checked my own live community's registration page, and it's served over HTTPS.  I checked yours, and it's not.  So .... maybe something isn't configured correctly on your server or htaccess?  (Because that would be embarrassing ...)

2.  Don't get drawn into an argument over the definition of the word "bug."  It's entirely a literary definition and it's stupid that another IPS client will bring that up, since debating over a word's definition is irrelevant to solving anyone's problem.  

3.  An ad hominem attack against @opentype isn't going to get you anywhere.  If you want to vent, 'Barneys Girlfriend' to someone in IPS Management and not a fellow client.  We're all in this together, and we all received the same Google notice as you did.  

[sadams101]

Thank you Joel R, nice to have a response in this forum that is helpful. As for me posting this in this in Product Feedback, as mentioned, I started this by creating a ticket and reporting it the proper way, but  Marc Stridgen says:

Quote

The login over https would cover the login pages only, and not the registration page. In order to have the registration page over https, you would need to switch the site over to https as a whole.

Kind Regards,
Marc Stridgen

So now I am very curious how yours could be working, as he seems to acknowledge that this is a known non-issue. He did install a new skin on my site and tested it, as I see the IPS Support skin he added yesterday, so it isn't my skin (I tested this too). I also checked my htaccess, and nothing there is redirecting it. Would you mind telling me the URL to your site?

[Martin A.]

Chrome 56 (beta) will throw the "Not secure" warning regardless of the "login over HTTPS" setting, as long as your site isn't completely running on HTTPS. That's because the login popup is shown on a non-secure page, even though the form will be submitted over HTTPS. Might be a bug in Chrome, and it'll change when the stable version is released.

 

And the register form should honor the setting.

return \IPS\Output::i()->output = \IPS\Theme::i()->getTemplate( 'system' )->register( $form, new \IPS\Login( \IPS\Http\Url::internal( 'app=core&module=system&controller=login', 'front', 'login', NULL, \IPS\Settings::i()->logins_over_https ) ) );

@bfarber @Mark

[sadams101]

Hello Martin, thank you for the reply, but please re-read the email that google sent me--this is a different warning than you refer to, as it won't begin happening until 1/1/17. Also, the warning will be triggered on every single page on my site because every page links to a non https registration page, thus, every user not logged in will see the warning on each page they try to load.

To be clear, is the code you offer here a fix that would make the register page go to https? Sorry, but that wasn't clear in your post. If so, where does it go?

[Colonel_mortis]

46 minutes ago, Martin A. said:

Chrome 56 (beta) will throw the "Not secure" warning regardless of the "login over HTTPS" setting, as long as your site isn't completely running on HTTPS. That's because the login popup is shown on a non-secure page, even though the form will be submitted over HTTPS. Might be a bug in Chrome, and it'll change when the stable version is released.

 

And the register form should honor the setting.

return \IPS\Output::i()->output = \IPS\Theme::i()->getTemplate( 'system' )->register( $form, new \IPS\Login( \IPS\Http\Url::internal( 'app=core&module=system&controller=login', 'front', 'login', NULL, \IPS\Settings::i()->logins_over_https ) ) );

@bfarber @Mark

That's not a Chrome bug, that is very intentional.

Both Chrome beta (56) and Firefox beta (51) will be visibly insecure (rather than simply not visibly secure as they are now) if there are any password inputs on the page. It's not an interstitial page or anything like that, just a marker/message in the address bar.

In firefox, it looks like this: while in Chrome where you currently have an (i) in the address bar it will say "Not Secure" (I can't seem to force it to show now using a pre-release build though).

If you are not logged in, all pages contain a password field, because they have a login dropdown. Making the registration page load over https is a very good suggestion, but it is not the solution to your problem. The solution to your problem is to force the entire site to load over HTTPS. Switching from HTTP to HTTPS will not have a significant impact on your Google rankings in the short term, and in the long term it will boost them because sites loaded over HTTPS are ranked higher than those loaded over HTTP.

There are no excuses left for not switching to HTTPS - it only benefits your site (potentially faster load times, extra features available to developers, better search engine optimisation, not to mention that it's actually secure).

[Martin A.]

18 minutes ago, sadams101 said:

Hello Martin, thank you for the reply, but please re-read the email that google sent me--this is a different warning than you refer to, as it won't begin happening until 1/1/17. Also, the warning will be triggered on every single page on my site because every page links to a non https registration page, thus, every user not logged in will see the warning on each page they try to load.

It says "January 2017", and that's probably when the stable version of Chrome 56 comes out. That version is currently in beta, which I'm using, hence why I'm seeing these notifications now. It'll only trigger once you open the login popup, and linking to the registration page will not trigger it.

18 minutes ago, sadams101 said:

To be clear, is the code you offer here a fix that would make the register page go to https? Sorry, but that wasn't clear in your post. If so, where does it go?

Nope, that's the code in the suite. Just added for reference to those who know what to do with it, such as the developers I mentioned.

7 minutes ago, Colonel_mortis said:

That's not a Chrome bug, that is very intentional.

Why is entering personal data on a non secure page considered insecure when the actual transfer is done on a secure line? 

But yes, changing the entire site to HTTPS is the way to go.

11 minutes ago, Colonel_mortis said:

(I can't seem to force it to show now using a pre-release build though).

Before login popup is opened: , and after  (Not secure)

[Colonel_mortis]

2 minutes ago, Martin A. said:

Why is entering personal data on a non secure page considered insecure when the actual transfer is done on a secure line? 

Because while you are protected against passive attackers in that case, you are not protected against an active attacker who has injected a script into the page to read credentials from the page when entered and send them back to the attacker. Also, doing it this way means that site operators can't bypass the warning by setting the form action to https, then overriding it in JS to actually sent to a HTTP origin. While that is pretty stupid, I suspect some site operators would do that to try and avoid the browser warning.

[Martin A.]

10 hours ago, Colonel_mortis said:

Because while you are protected against passive attackers in that case, you are not protected against an active attacker who has injected a script into the page to read credentials from the page when entered and send them back to the attacker. Also, doing it this way means that site operators can't bypass the warning by setting the form action to https, then overriding it in JS to actually sent to a HTTP origin. While that is pretty stupid, I suspect some site operators would do that to try and avoid the browser warning.

After reading a bit about it, I stumbled across a post in IE Blog from back in 2005. All in all just submitting these forms over HTTPS is a terrible idea. 

"How does the user know that the form is being submitted via HTTPS?  Most browsers have no such UI cue"
"If the login form was delivered via HTTP, there’s no guarantee it hasn’t been changed between the server and the client.  A bad guy sitting on the wire between the two could simply retarget the POST to submit to a HTTPS site that he controls.  Oops."

[sadams101]

2005? Sorry, but submitting passwords and logins over non https is considered a really bad idea by anyone.

[opentype]

Please try harder to first understand and consider what people are saying to you instead of instantly arguing against them or even attacking them. That 2005 article actually makes your case.