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

    • JetBrains is working to cut false positives in RustRover 2026.2 by David Uzondu Recently, JetBrains released the fifth EAP build of its dedicated IDE, RustRover 2026.2, bringing improvements like a Run gutter icon for criterion_main! macro benchmarking and a feature that alerts you when there are unused traits in your current scope. Now, the company is out with a blog post addressing one of the "most common" complaints from users: false positives. In RustRover, a false positive occurs when the editor incorrectly highlights something as an error even though the project compiles and runs successfully. This mismatch flags a gap between the IDE's internal intelligence and the actual compiler. When the editor flashes red warnings over perfectly valid code, developers lose trust in the tool, which stalls momentum. Traditionally, RustRover runs cargo check to detect compiler errors and warnings, but it also relies on its own code analysis engine to power real-time features. To provide quick feedback, this engine parses your source code into a syntax tree while inferring types and resolving names as you type. Because this engine must work on broken, half-written code and react instantly, its logic sometimes diverges from the compiler's, producing false positives that do not exist in the compiler's eyes. JetBrains said that it has a "dedicated task force" focused specifically on identifying and fixing false positives by analyzing user reports and examining large-scale open-source projects. To speed up this process, the team built an internal system modeled after Crater, the famous Rust project that compiles and runs tests for every single crate published on crates.io. This automated pipeline compares the diagnostics from RustRover's analysis with actual compiler output to catch discrepancies before they reach users, ensuring smoother workflows. RustRover, for those who're unaware, is a dedicated IDE designed specifically for Rust developers. It's been around for a couple of years now, providing features like built-in debugging via LLDB, seamless cargo integration, advanced macro expansion, and HTML support. JetBrains distributes the app under two licensing models: a paid commercial subscription and a free option for non-commercial use.
    • Last year I bought the 2TB variant for $114 on Amazon. That's crazy that the 1TB is now 67% more expensive for half the storage, even with the newer T9 already on the market. And that's considered a good deal.
    • You can disable all non needed features from Brave. There is also Brave Origin which removes them entirely and it is free for Linux.
    • I wish I could use Brave but the tab suspension feature is horrible. It doesn't suspend them like Edge does. Even after 2h open with 70+ tabs (same as Edge), it has 2GB more consumption than Edge for no reason.
    • TeamViewer 15.78.4.0 by Razvan Serea TeamViewer is the fast, simple and friendly solution for remote access over the Internet - all applications in one single, very affordable module. Remote control of computers over the Internet, Instantly take control over a computer anywhere on the Internet, even through firewalls. No installation required, just use it fast and secure. Training, sales and teamwork, TeamViewer can also be used to present your desktop to a partner on the Internet. Show and share your software, PowerPoint presentations etc. File transfer, chat and more, Share your files, chat, switch the direction during a teamwork session, and a lot more is included in TeamViewer. TeamViewer key features: Cross-platform remote access (Windows, macOS, Linux, Android, iOS, IoT) Attended and unattended remote control Secure file transfer between devices Remote printing to local printers Multi-monitor support with easy switching Wake-on-LAN for sleeping devices Session links for quick connections (no password sharing) Web client access (no installation needed) End-to-end encryption (AES-256) Two-factor authentication and access controls AI-powered session insights and reporting Mass deployment and device management tools Customizable allow/block lists for security Command line and script execution remotely Performance monitoring and analytics dashboards TeamViewer 15.78.4.0 changelog: Improvements Permissions inheritance has been improved, increasing reliability when permissions are assigned to user group managers. Bugfixes Fixed a bug where 'Show details' button was not showing up on command bar upon selection of a device group. Fixed a bug which was causing the legacy groups to disappear when applying hide offline filter in basic view. Fixed a bug where devices were loading infinitely after login. Fixed a bug which was causing crash in application. Download: TeamViewer 15.78.4.0 | 32-bit | Portable | Mac | ~70.0 MB (Free for personal use) View: TeamViewer Home Page | Release Notes | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
  • Recent Achievements

    • One Year In
      Primer1st earned a badge
      One Year In
    • Experienced
      JayZJay went up a rank
      Experienced
    • Reacting Well
      Sir_Timbit earned a badge
      Reacting Well
    • Week One Done
      rubentuben8 earned a badge
      Week One Done
    • Week One Done
      ARaclen earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      524
    2. 2
      PsYcHoKiLLa
      232
    3. 3
      Edouard
      135
    4. 4
      ATLien_0
      88
    5. 5
      Steven P.
      82
  • Tell a friend

    Love Neowin? Tell a friend!