Change your passwords

[Karlos]

Dear all,

Several accounts here have been compromised in recent days. We have no evidence at this time to suspect that the server itself has been compromised. So far the issue appears to be one brought about through the use of weak passwords used across multiple forums as all of the known compromised accounts have been misused on other forums already.

With that in mind, please change your passwords for this and every other amiga forum you visit, making sure each one is unique and as strong as possible (use mixed case, numbers and symbols where you can, the longer the better).

We apologise for any inconvenience.

[Karlos]

Oh, you mean *******, hey that's odd, when I type it I just get stars. :/

:lol:

For those not following, see: http://bash.org/?244321

[Karlos]

Hypothesis: Wasn't one of the reasons Wayne moved away from Xoops the presence of some significant security holes?

There were a number of issues. The version of XOOPS that this site used previously (which I believe was even more obsolete than the install at AW) had weak hashing for passwords. However, the main impetus for moving to vB was that the hosting provider was set to remove all support for older PHP versions and associated libraries as part of a managed update to 5 (again, for security reasons). The version of XOOPS that was installed, which was extremely outdated by then proved to be incompatible (bits worked, other bits didn't, basically a classic legacy PHP4 style application struggling with changes to the Zend engine since PHP5) with the updates.

The decision to move to vB was down to a choice between an updated version of XOOPS that would work after the update but be problematic for all the old amiga browsers, or some other platform. The only reason the site stuck with it's ancient version XOOPS for so long in the first place was for classic amiga browser compatibility (that and the fact that there was no upgrade path for most of the installed modules, either). With that consideration being out of the window regardless, alternatives were evaluated and vB was chosen as it scored better on a number of critical areas, including security.

Maybe the AW.net server is the weak point. Is anyone in touch with the admins over there?

Yes, we're in touch and cooperating on the problem.

Fortunately, the only other place I'm registered is Morphzone, and my password there is so convoluted that even I can't remember it!

Just did a passwd Matt_H, nonetheless.

That's for the best. No matter how strongly we salt and hash your password, if it is the same as you use on half a dozen other sites and one of those is the weak link, there's not a lot we can do other than reset it for you.

So once again folks, change your passwords if you haven't already and under no circumstances use the same password on more than one forum!

[Karlos]

All joking aside, this is a very serious issue.

The individual responsible has a tendency to change the email address associated with the account such that any attempts by the legitimate owner to request a new password will be in vain. Consequently, accounts that have been compromised will have their passwords and email addresses totally reset. The legitimate owners of any such account will have to contact us directly to have their email address restored. After which, they will be able to request a new password via the regular mechanism.

We are still investigating the possibility that this site was compromised directly though I so far nothing untoward has been spotted.

[Karlos]

That could be down to load. I've just been recursively checksumming all the files on the site against their last known state. It's an expensive operation.

[Karlos]

I hope a.org doesn't store the password hashes unsalted? Reasonably salted hashes are next to impossible to crack (reverse).

We're using a salted hashing algorithm for passwords.

[Karlos]

Unfortunately this is no longer true. Salting is an affective defense against rainbow tables, but there are new tricks in the bag: a single graphics card can try several billion vBulletin salted passwords per second and you can have several cards in a single machine.

In general salting is almost pointless if the attacker can obtain the salts (and typically they do, they're in the same table as the password hashes). Salts of course do raise the amount of work required for cracking but the GPU grunt has leveled the field again.

The solution is to use multi-round hashing of the password + salt.

I've written such a system previously, using a minimal 12 byte (all non-zero values allowed) random salt. The salt is merged into the password and the result hashed repeatedly with one of a number of supported hash functions (bcrypt is nice and slow as a proper alternative that does this stuff already). The salt and variable (up to 65535) iteration count is then encoded into the resulting hash rather than being stored separately. Depending on the settings applied, hashing takes up to 2 seconds on my PC.

It might be an option for this place if the worst comes to the worst, but I'd be reluctant to deploy it unless it was reimplemented in C and deployed as a compiled php extension such that the code is kept away from casual inspection.

[Karlos]

Pass the Salt!

ITYM "salt the pass"