Neowin needs HTTPS login from main, not just forums


Recommended Posts

Doesn't PHP Ioncube already give a bit of protection? I use Invision, and it seems that the board is built well enough to not need SSL.

 

Not serving the form over HTTPS exposes it to manipulation even if subsequent logging in action is done over a secure connection.

 

I think Subs get https..

 

Not in the list of advertised benefits, so I didn't want to assume.

Not serving the form over HTTPS exposes it to manipulation even if subsequent logging in action is done over a secure connection.

 

 

Not in the list of advertised benefits, so I didn't want to assume.

I'm not even 100% sure.. A mod will have to verify.. 

Not serving the form over HTTPS exposes it to manipulation even if subsequent logging in action is done over a secure connection.

 

 

Not in the list of advertised benefits, so I didn't want to assume.

Yep that is true - not sending the login form over HTTPS allows a Man-In-The-Middle attack, where the attacker can modify the form before the browser gets it, and redirect the login requests through his own server to capture passwords.

If you use different passwords for every site and change your password on a regular basis, then this shouldn't be a concern. :)

 

Also, HTTPS login is available for subscribers: https://www.neowin.net/forum/topic/1169735-https-sessions-active-for-tier-2-subscribers/

If you use different passwords for every site and change your password on a regular basis, then this shouldn't be a concern. :)

 

Also, HTTPS login is available for subscribers: https://www.neowin.net/forum/topic/1169735-https-sessions-active-for-tier-2-subscribers/

 

A potential for Man in the Middle attacks should always be a concern, irrespective of your password management policy. HTTPS login is available for mere mortals too, there is no need for a sub, it's just the form that is presented for you to enter your uber secure credentials is sent over HTTP rather than HTTPS, hence the MITM attack vector.

A potential for Man in the Middle attacks should always be a concern, irrespective of your password management policy. HTTPS login is available for mere mortals too, there is no need for a sub, it's just the form that is presented for you to enter your uber secure credentials is sent over HTTP rather than HTTPS, hence the MITM attack vector.

Well, most other forums don't have encryption by default either, so my type of password management is recommended. Sure it's not perfect, but it does mean that if some person does decide to attack then they only get the password for that one site (which can be reset after the person is done attacking) Another thing, the reason it's not encrypted for everyone is because the ad providers don't support it as mentioned in the topic I linked to in my previous post.

Well, most forums don't have encryption by default either, so my type of password management is recommended. Sure it's not perfect, but it does mean that if some person does decide to attack then they only get the password for that one site (which can be reset after the person is done attacking) Another thing, the reason it's not encrypted for everyone, is because the ad providers don't support it as mentioned in the topic I linked to in the previous post.

 

Sorry, but your point about ad providers not supporting encryption is moot in relation to displaying the log-in form over HTTPS when using Chrome or Firefox, because for neither browser any ads are displayed on the log-in page. It is applicable to IE, but if ads cannot be excluded on that one page for the sake of better security, it's pretty sad.

 

As for most forums not having encryption, encryption of what are we talking about? You can do authentication via HTTPS, you can serve the log-in form over HTTPS and you can generate random session IDs. Good password management by users does not absolve site operators from following security best practices.

Sorry, but your point about ad providers not supporting encryption is moot in relation to displaying the log-in form over HTTPS when using Chrome or Firefox, because for neither browser any ads are displayed on the log-in page. It is applicable to IE, but if ads cannot be excluded on that one page for the sake of better security, it's pretty sad.

 

As for most forums not having encryption, encryption of what are we talking about? You can do authentication via HTTPS, you can serve the log-in form over HTTPS and you can generate random session IDs. Good password management by users does not absolve site operators from following security best practices.

OK, but at the last of the day it's the admin's/dev's decision whether they implement for all, not ours.

 

It costs quite a bit of money so most have no SSL whatsoever. You can't really expect every forum to provide encryption.

Do self-signed certificates get along well with browser security? If the browser doesn't trust a certificate's issuer, then it inherintly does not trust the certificate. Self-signed certificates are their own issuer, which causes issues for situations like this.

Self-signed certificates are fine, you just get prompted when accessing it through HTTPS.  Not hard to implement at all and it wouldn't hurt anything.  They don't have to be expensive, either.

Self-signed certificates are fine, you just get prompted when accessing it through HTTPS.  Not hard to implement at all and it wouldn't hurt anything.  They don't have to be expensive, either.

that's fine for an intranet but that's really bad practice for a live website. would YOU trust a random website that used a unsigned certificate?

OK, but at the last of the day it's the admin's/dev's decision whether they implement for all, not ours.

 

It costs quite a bit of money so most have no SSL whatsoever. You can't really expect every forum to provide encryption.

 

I understand that it's a decision for the developers/admins. What I am asking for is not full blown SSL everywhere, so you may have things confused. Since the submit form is already securely processed, it should not be too much effort to present the form itself over HTTPS. It is already possible to have it loaded with SSL by manually editing the URL and changing HTTP to HTTPS, so I cannot understand why it is not the default behaviour.

 

Self-signed certificates are fine, you just get prompted when accessing it through HTTPS.  Not hard to implement at all and it wouldn't hurt anything.  They don't have to be expensive, either.

 

If you think self-signed certificates are just as good as those issued by a trusted CA, I have a bridge to sell.

 

that's fine for an intranet but that's really bad practice for a live website. would YOU trust a random website that used a unsigned certificate?

 

I wouldn't even go as far as saying that it's OK for an Intranet site, because accepting self-signed certs over and over desensitises users and lulls them into a false sense of security when they come across that on de Interwebz.

 I understand that it's a decision for the developers/admins. What I am asking for is not full blown SSL everywhere, so you may have things confused. Since the submit form is already securely processed, it should not be too much effort to present the form itself over HTTPS. It is already possible to have it loaded with SSL by manually editing the URL and changing HTTP to HTTPS, so I cannot understand why it is not the default behaviour.

I know that's what you are asking for and while it's possible on this forum. I don't think the devs want to mess with the ad code on the login page just for HTTPs since they weren't even keen on adding the encryption for subscribers either at first. Then again, I don't know and am just making guesses based on the information found on the FAQ in that topic posted earlier. 

 

Anyways, I fully understand why you would want it, but I'm not sure that it'll get implemented. However, if it does then that's great.  :)

We are aware of the insecure login form on the front page (the forum has a dedicated secure login page). I haven't decided on how to fix this yet. I think the only way is to redirect to a dedicated secure login page or at least mention that this main page login isn't as secure as it should be and add a link to the forum login page.

 

Subscribers do have full site encryption

 

We are not providing full site encryption for everyone because of the ads. We need them....

The cheapest I know are around $16 / year, so I wouldn't really call it expensive, if you buy from the right place. But yeah, it is up to the admins^.

I've had them as low as $4/year. Less if it's multiple years.

 

A redirect to a secure login form would be a good idea, Redmak.

We are not providing full site encryption for everyone because of the ads. We need them....

 

Lame-ass Netshelter ads :P

 

I don't get why those big ad providers don't fix their HTTPS. Personally I'm a big fan of just using HTTPS everywhere. It'll be a requirement in the net HTTP protocol (probably SPDY) anyway. And it provides easy protection against sniffing.

Self-signed certificates are fine, you just get prompted when accessing it through HTTPS.  Not hard to implement at all and it wouldn't hurt anything.  They don't have to be expensive, either.

They work, but they don't provide any trust, which is honestly the most important aspect of TLS.

We are aware of the insecure login form on the front page (the forum has a dedicated secure login page). I haven't decided on how to fix this yet. I think the only way is to redirect to a dedicated secure login page or at least mention that this main page login isn't as secure as it should be and add a link to the forum login page.

 

Subscribers do have full site encryption

 

We are not providing full site encryption for everyone because of the ads. We need them....

I think redirecting to a dedicated secure login page is a better approach to take. Not suggesting full-blown encryption everywhere for everyone for a minute, I appreciate that you guys need the ad revenue.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Promoting is fine - advertising, informing, whatever.  But interrupting your PAID OS experience is not.
    • Why does a PDF software need an audio player inside it. What is this bloat.
    • Sadly, that is the state of things. It's basically considered acceptable for any random app running on your computer to use 1+ GB of RAM, and install space, lol, no one even seems to consider that.
    • EU Commission explains why Siri AI isn't launching in the EU, and Apple is to blame by Hamid Ganji Image via Apple This week at Apple’s 2026 developers conference, the iPhone maker unveiled the upgraded Siri after more than a year of delays. The new Siri is now called Siri AI, and it's powered by Google Gemini models. While Siri AI is preparing to roll out to Apple users worldwide, the company’s EU customers might need to wait much longer before getting their hands on the new assistant. Shortly after announcing iOS 27, Apple said in a blog post that Siri AI is not coming to the EU anytime soon due to hurdles posed by the Digital Markets Act (DMA) and other regulatory requirements. To comply with the DMA in the EU, Apple apparently needs to open Siri AI to rival assistants on iOS 27 and iPadOS 27. Apple has refused to do so, which has resulted in Siri AI being delayed for its EU users. The company argues that such a move would put users’ privacy at risk. In a statement to Neowin, a European Commission spokesperson provided more details about why Siri AI will not be rolled out to Apple customers in the region. The statement first noted that the DMA does not prohibit Apple from launching its services in the EU and that the company is simply required to comply with the law. The European Commission spokesperson added that, since Apple is considered a gatekeeper under the DMA, it is “obliged to give third parties access to equivalent features as they give to its own products. Because the DMA is precisely about giving users the choice to use the product they find best suits their needs.” Moreover, the spokesperson said the Commission has been in contact with Apple, though the company “did not develop proposals for DMA compliant interoperability solutions.” The statement also clarified that companies designated as gatekeepers cannot leverage their status and products, such as operating systems, to favor their own AI services. The first public beta of iOS 27 will roll out next month, while the stable version is expected to launch this fall following the release of the iPhone 18 series. It remains unclear when Apple will be able to resolve its DMA-related compliance issues with the European Commission and bring Siri AI to its European customers.
  • Recent Achievements

    • One Month Later
      pinnclepd earned a badge
      One Month Later
    • First Post
      X-No-file earned a badge
      First Post
    • One Month Later
      johnjacobb40 earned a badge
      One Month Later
    • One Year In
      Primer1st earned a badge
      One Year In
    • Experienced
      JayZJay went up a rank
      Experienced
  • Popular Contributors

    1. 1
      +primortal
      510
    2. 2
      PsYcHoKiLLa
      214
    3. 3
      +Edouard
      145
    4. 4
      Steven P.
      88
    5. 5
      ATLien_0
      83
  • Tell a friend

    Love Neowin? Tell a friend!