PeterUK

Phasing out BBCode and going for all-HTML down the road is a good thing, it just needs to work correctly.

 

People get all sorts of annoyed when they go to edit a post and some new behind the scenes change which they don't care about totally messes it up and causes a load of work for them.  Also in general, most users hate changes and it discourages them from posting because they don't want to bother getting to grips with something new.

 

The most important thing though, and it's been said by everyone here, is it needs to have total backwards compatibility.  Parsing some BBCode into HTML but they might not turn out exactly how the BBCode displayed things?  Then don't parse them and save it that way, you need to save the original so that the content as it was intended to be displayed isn't lost because of some screw up made in conversion. 

 

I always love to upgrade our forums and get the latest features, but the biggest worry for me is always that some change that has been made (just like this) might cause our users to dislike the forum and thus posting will go downhill.  It's also not IPS that takes the blame when this happens, our users hold us responsible and we suffer for it as well.

It seems that despite this post:
http://community.invisionpower.com/topic/347987-bring-back-the-31-standard-editor-as-an-option/page__st__120#entry2193192

Matt has clarified in his recent blog post (check the comments) that we will not be getting an editor which has working buttons when RTE mode is disabled, it will remain the same way it is now (press the toggle in the top left of the editor, and while you can edit the raw BBCode here, all of the buttons which make BBCode easy to use will be disabled).

I thought the previous feedback topic was locked because it was resolved that we would get an editor which works that way, but it appears not, so presumably another feedback topic is now appropriate?

There are many people who still use the standard editor all the time, or even if only for a few minutes to fix a post or edit a difficult-to-manage-in-the-RTE one, and not having the BBCode buttons is a pain.

I already know how to edit the tempates and have already done so. But thing is I hate editing templates because of upgrades and try to avoid it. If it was a setting then that would be great. Besides we still need the ability to send a PM upon warning. I think that's a lot more important than viewing warn points, and that can't be achieved with a simple skin edit. Should that be a separate thread?

Agree, it would be nice if it would send a PM from the moderator who issued the warning informing the user.  On our forum everyone has the right to question warnings they are given by moderators and we're now going to have to get our moderators to add a line to the bottom of the user viewable reason with something like "If you wish to discuss this warning please PM me.".

Actually Google's two step verification uses time based keys and thus you don't need to worry about sending SMS at all.

The server simply calculates what the input key should be based on the current time (and usually a key 5 minutes either side to account for the user's device time drift) and the private key generated for that user, and then simply compares that with the user's input.

I would love to see this method available to enable (as opt in for users) on IPB.  Although the private keys should be encrypted in the database if this was to be implemented.  The PHP function openssl_encrypt() is really good for two-way encryption but was unfortunately only added to PHP natively very recently.  If an intruder got the private key because it was unencrypted, they can just add the generator to their own Android device (or emulator) to generate valid keys for the user.

EDIT: I actually have some PHP somewhere which generates keys and the relevant codes based on the time, I'll see if I can find it...

You could encode the file although that seems a bit over the top.

I was thinking the same thing as the only ultimate solution.  Use Zend Guard or ionCube to encode the PHP file with the details in (except the author of the mod would have to do that before sending it out for each different user).

Thanks to an unfortunate series of events, we recently had our entire user database stolen. In the two weeks since, we have had numerous lists published containing that information as well as thousands of their cracked, plaintext passwords.

I don't know how they are cracking the hashes, but it doesn't much matter. It seems clear that IP.Board's password hashing system is no longer entirely adequate for widespread and conscientious use.

I implore IPS to investigate moving to a new password hashing scheme. Perhaps that means making use of newer and stronger technologies than MD5. Perhaps that simply means changing to a more lengthy and complex hashing process. Whatever the case, something needs to change.

When everything else has gone wrong, password hashes should be the one thing that doesn't.

The hashing system is still fine, the main problem are weak passwords, and as others have said, more processing power.

The problem is (and we know this all too well ourselves), when the DB is leaked, the salts come with it, and once you have the salt, IPB's hashing method adds a couple more MD5 calculations to the process which does slow things down a little, but ultimately it's down to how secure the user's password is.

I believe the hashing method for IPB is:

md5(md5($salt) . md5($password))

So there's 3 MD5s to calculate but you can presume if they're trying to get a specific user's password, they will precalculate the hash of the salt and then all they have to do is plug that in to one of the multiple MD5 crackers out there and wait for it to get brute forced.  

One thing that might help is to store a salt somewhere in a config file and use that salt *as well as* a salt stored in the database.  More experienced users could modify the value in their config to something custom (and huge) and it would make cracking the passwords pretty much impossible without also getting hold of the config file with the other salt in when they stole your database (which means compromising the server as well as just stealing the DB).

The other problem apart from brute forcing is of course dictionary attacks... and then back to brute forcing... just look how cheaply you can rent an Amazon EC2 Instance with a bunch of nVidia GPUs in it, one single graphics card in one of those things can crack at least 1B hashes/sec each (probably more, now I feel like testing it).