Thoughts about replacing vBullettin with another forum solution?

[jman]

Originally Posted by meynaf

Don't have me started on security of old things

Exactly:

https://web.archive.org/web/20240715...emonamiga.com/

[RCK]

For me, EAB should stay as it, with the old vb3 engine, because of the speed, nostalgia, and amiga compatible
I don't care about mobile skin, double authentication, etc. but we have to be "findable" by search engine to not be useless.

Now, if we want to keep abime.net server secure, I have to keep kernel and linux packages up to date, because this server is online 24/24.
This means PHP versions are always growing (EAB is running on php 7.x, but php 8.x will be soon live, etc.)

So I will do the maximum to patch the php code and let it work with the latest PHP version.
But maybe one day it won't be possible anymore, and if it happens, I will be forced to make a poll to choose between security (new forum engine) or unsecure EAB.
Hopefully it won't happen soon

[meynaf]

Updates have their own issues, look at what happened with CrowdStrike.

[gimbal]

CrowdStrike hooks into kernel space, that is a whole different level of update disaster. But what would be even worse is if they would stop pushing those updates.

[modrobert]

Originally Posted by RCK

For me, EAB should stay as it, with the old vb3 engine, because of the speed, nostalgia, and amiga compatible
I don't care about mobile skin, double authentication, etc. but we have to be "findable" by search engine to not be useless.

Now, if we want to keep abime.net server secure, I have to keep kernel and linux packages up to date, because this server is online 24/24.
This means PHP versions are always growing (EAB is running on php 7.x, but php 8.x will be soon live, etc.)

So I will do the maximum to patch the php code and let it work with the latest PHP version.
But maybe one day it won't be possible anymore, and if it happens, I will be forced to make a poll to choose between security (new forum engine) or unsecure EAB.
Hopefully it won't happen soon

From experience, being familiar enough with the PHP code to patch it increases the security a lot, and I like your plan.

Originally Posted by meynaf

And if for whatever reason you don't have a mobile phone at all (or an ancient model), you're stuck.
The only effects of 2FA is to block legitimate actions and collect personal data with the excuse of security.
If EAB starts doing that too, I will leave permanently.

I think 2FA (MFA in general) improves the security theoretically, but the price is high in practice, definitely too high for certain situations. In most cases you are required to use an app running on your smartphone (aka "ankle monitor") which is constantly monitoring your position and listening in as needed. Suddenly it becomes a matter of who you will trust (best case the phone manufacturer holding the cryptographic keys and the government with access to them), not about maximizing security.

A working compromise for me is to never forget what the smartphone is, "an ankle monitor for the modern world", and leave it behind in certain situations.

Originally Posted by jman

Speaking about security, I feel it's less secure using an unsupported version of vBullettin (3.8.x has reached End Of Life in 2017, see announcement) and the obsolete and unsupported PHP stack that it has to use.

In my experience, it's better to know the PHP code you are running and being able to patch it. Let me give you an example which is completely made up regarding the security flaw, just for the sake of explaining.

In vBulletin you have the "?p=123" parameter which takes you to post 123 in this case. Let's say a security flaw is reported where someone manages to inject an SQL string into this "p" parameter which does some nasty query on your database.

The bug is disclosed in public and an official patch is released which changes the SQL query to be quoted differently in the PHP code.

Solution 1 (following guidance, not knowing the code):
You apply this patch by updating, and feel good about yourself.

Solution 2 (thinking yourself, knowing the code):
You quickly realize that the "p" parameter should never accept anything except integers, since you know the code, you add code which check if "p" brings an integer, if not you reject the parameter and give http error "403".

"Solution 1" will fix the bug for the specific attack used to compromise the "p" parameter, while "Solution 2" will future proof your code by preventing any SQL injection attacks regarding the "p" parameter ever again. As an added bonus the quick http error "403" exit in your code prevents DDOS attacks unintentionally created by hoards of bots trying to exploit the announced bug. Also, "Solution 2" lets you patch code which isn't officially supported anymore.

[meynaf]

Originally Posted by gimbal

But what would be even worse is if they would stop pushing those updates.

Why would it ? I can't think of a single example of comparable catastrophic result because some update hasn't been made.

[AestheticDebris]

Originally Posted by meynaf

Why would it ? I can't think of a single example of comparable catastrophic result because some update hasn't been made.

SQL Slammer springs to mind. Although there have certainly been plenty of cases of old software with known vulnerabilities being exploited.

[meynaf]

Originally Posted by AestheticDebris

SQL Slammer springs to mind. Although there have certainly been plenty of cases of old software with known vulnerabilities being exploited.

Ok then.
Nevertheless the situation is slightly different. Pushing updates all the time isn't exactly the same as an emergency fix. Was CrowdStrike update a security fix or did it contain a shitload of other things (especially that users didn't want) ?