insecure login

The webmaster of this site has chosen for years not to upgrade to SSL. Probably more because of the perceived hassle to do the migration rather than cost.

My professional recommendation is to use a totally random password that you do not use for anything else at all. No your email, not your bank, NOTHING. This should be the only site in the entire world that you use this password and it should not bear any resemblance to any other password.

Also remember, that this website is hosted on an old version of vBulletin. One does not need to do an in depth security audit to know that there are numerous security vulnerabilities in this software. Simply search for it on the CVE database and find https://www.cvedetails.com/vulnerability-list/vendor_id-8142/Vbulletin.html.

Basically. This website, the content of all the posts, and the content of your private messages should be considered to be public anyway. :whisper:

I have minimal confidence in the security of this site. To me it's all public. But please, please do not use the same password that you use for anything else.

Austin said:

All you have to do is add s to thr HTTPS part and that should work.

Click to expand...

You're so close! Users should not need to add the HTTPS because you ultimately want to configure it to redirect to HTTPS on first visit to port 80 and then set an HSTS header to declare that the site is SSL only.

But you have a few steps to do first.

Do you have access to manage the templates for this site? What you need to do is to search and replace the references to http:// with any include scripts, such as "http://www.georgiapacking.org/forum/clientscript/ncode_imageresizer.js?v=1.0.1" in the forum source and replace it with a protocol relative inclusions // or https://. Then the error will go away. Basically, for any page that shows a "this page is encrypted but includes insecure resources" use view source and search for any instances of "http://". Those are the references that need to be updated.

See https://www.paulirish.com/2010/the-protocol-relative-url/

AtlPhilip said:

Why take the time to secure content in transit that ia ultimately going to be public anyway?

Click to expand...

In most cases SSL is needed to 1) provide session security and guard against account takeover, 2) to prevent ISPs from meddling with content in transit, and 3) SSL content is delivered faster in many cases because of technical reasons.

Most people use the same password they use elsewhere (or highly related). The disclosure of of which can lead to major problems. It is imperative for sites even like this to follow pristine user management practices to avoid opening users up to unnecessary risk. Sadly in infosec there are no good neighborhoods. Every site, both a bank and a forum must defend against the best hackers in the world.

But SSL alone doesn't help you if a SQL injection attack against un-patched software leads to a disclosure of unsalted SHA1 password hashes (if this site were to use those for example. In such a case, a disclosure of the users table through such an attack would be a reportable data breach under Georgia law OCGA 10-1-911.

I personally only interact with this site with information that I plan on being public and I use random password that looks like tihs (not the one I use here) H17zU8gPlmxIfiA2Yhjvjo67UKJJKbb2SaNO8HckcEI/RXSZIcwbtmfEv+qLp5BWzHwkdpPX+E1lISaevSkLtw. However, most people are not taking those precautions.

In reality this website is not impenetrable.The admin has stated that he will routinely respond to subpoenas for information, possibly without even the level of pushback that a major social media site will give. So pretty much any US-based state or federal agency can ask for information, possibly without a warrant, and get it. Your ISP can and will log your activity and may turn it over for reasons. Furthermore, it is running an old open source bulletin board software that may or may not be completely up to date with its patches and which has had multiple CVEs published against this software, the server that its running on, and its dependencies. And even if that was not the case, this is not run as a high security site so if any hacker or state-sponsored security agency were to take an interest in this site or its content I have low confidence that it would withstand the attack in the current state. This is not based on any particular review of the site other than experience with what is typical in the industry with sites that I am more familiar with.

Frank

frankr said:

How so!?

The bolded, underlined section applies to almost EVERY website that has user logins.

Click to expand...

That's not how the law works. Paragraph one defines who the law applies to. It states:

"(1) "Breach of the security of the system" means unauthorized acquisition of an individual's electronic data that compromises the security, confidentiality, or integrity of personal information of such individual maintained by an information broker or data collector."

It then defines "information broker" and "data collector" in such a manner as to exclude this site.

Furthermore, neither this site, or its owner, reside in Georgia.

frankr said:

As for page speed, I would look at https://http2.github.io/faq/. It's not an accident that SSL is required for the HTTP/2 protocol. SPDY also leveraged SSL, mostly for cache busting.

Click to expand...

Thanks, but the linked content doesn't address my question. Http/2 is completely different than http 1.1, currently in use by 99.95% of the public internet. It improves performance by eliminating text transmission and reusing sockets, not by encryption.

And SSL/TLS with http/2 is mandated by the browser developers, not by the http/2 standard itself.

As for caching. Properly implemented, caching can significantly improve performance, especially where identical content is delivered repeatedly.