Note to CrackFox: scroll down to the very bottom of my post. That's the part that's for you.
Yes I understand that. I quoted him because in my opinion, it was worded in that he was confused as to why ANY password data was being stored, encrypted or not. [...]
Ok, fair enough. Now I get what you're trying to say here, but the word "encryption" implies that decryption is possible. Hashing is different from that, but I know what you mean.
- but make your own encryption, just don't tell them. [...]
Are you advocating that MacRumors (or even vBulletin) develop their own encryption cipher algorithms? That is almost always a bad idea! Published ciphers such as AES-256, Blowfish, etc. have been thoroughly studied and tested by many eyeballs. Custom, untested ciphers often contain unintended weaknesses. Security through obscurity is no security at all.
Read Arn's latest post. If the point you're trying to make is to simply use the best method of password protection vB has to offer, that's fine, but I'm sure when it comes to running a site like this, admins need to look at balancing the ease of implementation vs the additional benefits from those changes. It's easy for a user to say what MR's should be doing and such, but it's the admin(s) that need to do all the work for us. This isn't like updating an app from the App Store.
I'm a computer science student with an understanding of relational databases, cryptography, and forum software code including vBulletin. I have administered, maintained, and modified forums and blog software before (admittedly on a far smaller scale, 20-30 users as I recall), and I understand what would be involved in the PHP and database modifications.
vBulletin doesn't offer a choice of hashing algorithms. The use of MD5 is hardcoded into the PHP scripts, so the ideal place to fix it would be not at individual message boards, but upstream in vBulletin itself. Then sites like MacRumors would eventually migrate to the newer version (which requires reapplying backing up forum data, re-applying patches, testing the new system at a separate location, temporarily disabling the old system, and likely fixing problems with the update that were not discovered during private testing).
Look at it this way, if MR's wasn't compromised, there wouldn't be any posts about any hashing methods.
Not quite true. This same discussion of vBulletin's poor choice in hashing algorithm was also discussed during the Ubuntu forum breach. I'm also a member of those forums and I saw and participated in those hashing discussions.
So again the problem was a compromised elevated account and Arn provided the most sensible theory behind how it may've happened which had nothing to do with any hashing method.
I wasn't suggesting that hashing had anything to do with the vulnerability exploited to gain access. I am aware that the breach stemmed from elevated privileges on a moderator account with weak password. The problem is that once a database dump has been obtained by an attacker, poorly hashed and/or unsalted (in vBulletin's case, they're salted) passwords are more vulnerable to being uncovered using hashcat + password lists + rule sets. And if a database (not the MR database, I'm speaking generally) contains cleartext passwords, forget it. All accounts would be immediately vulnerable with no time for users to change their passwords.
Most of the posts admitting how some users re-use logins elsewhere are the faults of those users than it is MR's. It's not MR's responsibility to safeguard the carelessness/laziness of its users.
With this part, I 100% agree. I wish other computer users were more diligent about their security. My complaints are primarily in regards to vBulletin, not MacRumors.
Apologies in advance for my naivety.
Could someone please explain what the risk to a user is? What can the hacker do with the login info for a forum?
Cheers
The most vulnerable people are those who use the same password on other accounts, such as email, financial, medical, shopping, work, social networking accounts, or Apple ID (which can be used to locate and/or remote wipe a Mac or iOS device). An additional but smaller risk is private messages, because some of those inboxes and sent boxes contain information and conversation that was thought to be somewhat private, and some portion of it (however small) might be slightly sensitive.
Androiphone's explanation in the previous post is good, but to it I would add a link to my
summary comparison of three password managers.