Ryan H.

Sometimes the reviews may relate to important issues or queries, which could be resolved or clarified more quickly if the author is notified. I realize that the IPS Marketplace isn't intended for such, but IPS members seem to use it for such anyway, and in any case it could help on other sites.

Would it be possible to change how photo filenames are generated when a user uploads a new photo? This will allow those of us using a CDN to see photos update instantly when a user updates theirs.

I love that IP.Board makes it so easy to rewrite static URL's for use with a CDN, but many members are continuously pestering my staff and filling our "site problems" section with "Why do I not see my new photo?" questions as the CDN can take several days to re-cache a file (and the change may take even longer to flow down to users thanks to their browser caching it as well), when the fix to this would be as simple as ensuring that a new upload gets a new filename. Browsers and the CDN will then notice that it's a file they've never seen before and will be forced to download a fresh copy of it.

The current naming scheme uses "photo-<user ID>". As the filename is stored in the database as part of an account's data, changing the naming scheme for photos to, say... include a timestamp, could be done safely without breaking any existing photos. I can't imagine it would be too difficult to stick a timestamp or some random number into the photo's filename in the place where it is generated, but it's a change that my members and I would greatly appreciate. Every other forum package I've seen (including the free ones) has some way of ensuring that new avatars or photos get a new filename.

Rimi, on 26 March 2012 - 04:22 PM, said:

Use stronger passwords - problem solved

Ryan H., on 29 March 2012 - 07:18 PM, said:

I am not against making things better security wise, far from it. The thing to bear in mind is that most admins are not technowiz types what would make your eyes bleed (and mine) bad practice-wise would get a shrug from most other people. That's the admins for the users, generally, it is worse it is hair pulling difficult to get people to realise that reuse of password on multiple systems is a bad idea.

Making the 'front end' forum more secure is irrelevant against bad personal practices. All I am trying to get across is that changing the db storage hash is not going to achieve all that much, whatever method is used it can be reverse engineered by brute force. Making passwords into pass phrases is an improvement but even a pass phrase like 'James Kirk is the best Captain fer sher!' is side tracked if used on multiple systems. One bad egg capturing the plain text and using them not as brute force but trying the username/password pair is all it takes to bypass the best security.

FWIW I use RoboForm, for each site I get it to generate a unique password, it keeps them for me in an encrypted file and that is the only 'password' I need to remember it then will log me in, that's my solution trying to make users security aware is like eating soup with a fork.

One thing that could be done...

We currently do md5( md5(salt) . md5(password) ).  This is stored as the hash (along with the salt) for later comparison.  We could take this and then run it through another hashing algorithm (bcrypt, etc.) and then store that.  If we did that, we can update existing passwords in the database (just take the value from members_pass_hash and run through bcrypt or whatever is used).

There's some very good suggestions here. Not all of them are workable for widely distributed self managed software. If we were running SaaS, then we could be more confident in the hosting environment and implement specific things.

Some quick notes:

Blowfish/Crypt: I'm not against this but there are different algorithms and not all machines have the same algorithm which could mean all your password hashes become 'lost' if you move hardware. This will certainly end up back in our lap via a support ticket "I moved to a new host and now no one can log in".

SMS: It's just too costly and too involved to be a standard feature. It may make a nice mod but generally we're looking to lower the bar for registration and I think requiring a mobile phone number will put people off. For specialised more tolerant communities I'm sure it'd be fine.

Longer / Complex passwords: I agree we can do something here and I'll make a note for 3.4 to remove the maximum limit and add a setting in to control a minimum limit. Perhaps we can also add a setting to enforce upper/lower case, etc.

Changing the password hashing algorithm is going to be near impossible for existing boards of course. We don't store the plain text variant so the only way to switch to a new hashing method would be to wipe everyone's passwords upon upgrade and force everyone to reset via email. There's no point offering a dual log in (check new hash, if it fails, check old hash) because that doesn't fix the problem. A dual log in service would need to be maintained for years if that route was chosen.

This is a good productive topic, though!

When it comes to password security on a forum you're really talking about 3 possible scenarios:

• Someone is trying to brute force a members password by just trying random passwords in the login form.
  
• Someone is trying to automate a brute force attack on the login form
  
• Someone has stolen your database and is brute forcing your members passwords offline.

Scenario 1 and 2 are easy enough to prevent. First of all, only allow 1 login attempt per second. This will slow down automated brute force attacks to the point of being unfeasible. Trying to brute force a 6 character, lowercase a-z password at the rate of 1 per second would take 9.7 years (309 million possible combinations).

To prevent people randomly trying to guess passwords on the login form, after x attempts, start presenting a captcha on the login form to slow them down a bit more. Lets be honest, no-one is going to keep this up for long. I would put money on all of these types of manual "attacks" are just a user annoyed at being banned / warned and trying to guess an admins password to get back at them. Either way, they'll likely get bored fairly quickly and give up.

Whatever happens, don't lock the account. That's just punishing the real member for someone else trying to hack them.

For scenario 3, once an attacker has a copy of your database, there isn't really a whole lot you can do. The best option here is to use a slow crypt method like bcrype, or PBKDF2. These are specifically designed to make brute forcing a password a slow, long and painful experience.

When it comes to password / member security, it's important to remember the context. Does a forum need password security on the same level as an online banking website for example? The benefit vs hassle for the member needs to be considered.

With that in mind, I'd like to address your proposed list:

Ryan H., on 28 March 2012 - 08:46 AM, said:

I'd have no problem increasing the option default to 7 characters, but it must be an option. If I run a closed community with 3 members on a LAN and I want them all to have the same single character password of 'a', then that is my choice as the admin. The software should give me that choice, but also provide me with a warning / information that lets me make the right choice when I'm fiddling with the ACP settings.

Ryan H., on 28 March 2012 - 08:46 AM, said:

Agreed. As the password is hashed, so takes up a known amount of space in the users table, there is no reason to have an upper limit on the password.

Ryan H., on 28 March 2012 - 08:46 AM, said:

Agreed, see above.

Ryan H., on 28 March 2012 - 08:46 AM, said:

I believe this to be unnecessary. It would involve a lot of developer time from IPS to implement (different SMS gateways for different countries, keeping them all up to date, constant testing, and so on) and a lot of work for the admin to setup, not to mention a possible large bill for the uninformed admin who doesn't read the SMS gateway pricing fully before signing up. All this for a service that few sites would use, and even less users would use. Who wants the hassle of waiting for a slow SMS to arrive being being able to login? That's a forum I would never use. I think that IPS developers time could be better spent here.

Ryan H., on 28 March 2012 - 08:46 AM, said:

This option would be handy on the very rare occasion that a sites entire database gets stolen but how would it work? Would all passwords become blank, forcing the user to choose a new one when they logged in? If so, what is to stop anyone from randomly setting new passwords for any user? If the user is forced to enter their existing password first, then there is nothing to stop the attacker doing the same, as they have your database and have likely brute forced half your MD5 passwords by now. If a system like this where to be implemented, it would need to be done carefully (admins don't read warnings), and it would need some thought as to why the system is needed, and what could be done to prevent such a system being needed.

Ryan H., on 28 March 2012 - 08:46 AM, said:

I'm all for this, if I as an admin want to force my users to have upper case, numbers, and all manner of junk in their passwords, then I should be able to. Again though, this boils down to the cost vs benefits need to be weighed up. Will enough admins make use of it to warrant IPS developing it or is it an option that is better suited to an add-on?

Ryan H., on 28 March 2012 - 08:46 AM, said:

What's the use-case for this one? I'm not sure why you would want to do this.

Ryan H., on 28 March 2012 - 08:46 AM, said:

I'm all for logging every single admin action, IP.Nexus-style, but again, this is just a forum and database sizes need to be considered. How large would the admin_logs table be for a large site with 5 admins that has been running for 6 years? Also, these logs exist elsewhere. Apache for example logs every request and it is unlikely that these could be easily deleted by someone who has gained access to your ACP. Is duplicating this information in your ACP really needed?

Making the admin logs impossible to delete would also be tricky. Removing options from the ACP is fine but stopping them from just dropping the admin_logs table, or selectively deleting rows is a different matter.

At this stage, I think that the only option is to restore your site from a pre-hack backup rather than trying to see what the hacker has done and trying to undo their changes.

So to summarize: Slow down remote brute force attempts and use a slow crypt method, those are the options that get my vote

There is some intelligent and thoughtful discussion in this topic.

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...

Along these lines... do not FREQUENTLY turn your board offline. If you are doing maintenance, in which turning the board offline is necessary, then keep it offline until you know you are done. Turning them offline, then back online, then offline again because you found something else, etc is frustrating for your memberbase, and can have a larger negative impact then just keeping it offline for a prolonged period of time.

And, on that note, always notify your members first before turning the board offline for anything longer than 15-30 minutes, and schedule a time to do so. That way they simply know that the site won't be available within that timeframe and will be less frustrated about that fact.

It has now been almost 7 months since the last beta update of IP.Tracker.  I can understand being busy, but this has really gone on way too long without there being an update to this app.

Please, either devote some time to continuing work on this app, or turn it over to someone who will make time for it.  It's too valuable of a tool to sit there for this long without having its issues addressed.

EDIT: To clarify, I'm not asking to take it over personally, just that it get a little bit of TLC.

So, the dropdown menus on the user bar and on the main nav only work when Javascript is turned on. Granted, some features of IPB and the suite can only be used with Javascript (like this RTE I'm using here) but it does bother me when degradation is less graceful than it could be. The menus could easily be changed to ones that use CSS to pop open on hover, then a bit of JS to override that behaviour and implement on-click opening instead. I even made a little page to show how easy it is (although granted, I cheated and used jQuery instead of Prototype. You get the idea though). An added bonus is that, since the dropdowns will work all of the time, you can even put absolutely essential links like logout in them, as I've done there.

Having said all that, I'm sure you're aware of this issue and have already considered - and rejected - changing it. I'd be interested to know why.

bfarber, on 05 March 2012 - 11:14 AM, said:

Google's front-page can last forever. Just change the menu at the top every week.

We have all had these experiences when visting a community...

Rules and Regulations

I know I have visited communities where their rules, guidelines, terms, etc. are longer than most of their topics. I really do not like that approach as it's not very welcoming and, really, honestly at the end of the day no one reads or cares about the rules. People know what is proper and improper behavior and do not need to be told not to use profanity, make personal attacks, post in the wrong areas, etc. - written rules or not people will still be people and do that.

Take the rules here on the IPS Community:

Quote

I think that gets the point across. Don't be a disruption and you're good!

Way too many forums and sections

This is mostly true for new communities. You're starting a new community and are understandably excited so you create many categories, forums, and sub-forums. So many in fact that your home page scrolls and new members have no idea where to post. Not to mention the fact that your site looks like a ghost town with topics scattered about dozens of forums.

Having many sections makes sense once your community is established and you need organization to keep things easy to read. But when you are first starting try not to overwhelm your visitors with too many areas.

Too Wordy

Does your News forum really need a description that says "This is where we post news and information about updates to our site. I hope you read it and comment often as it's very important. Read this first!" ... I mean the title "News" kind of says all the same in one word. There's nothing wrong with description when needed but just because IP.Board has a "Forum Description" box there when creating a new forum does not mean you have to fill it out.

Ask yourself if a forum you're creating needs a ton of explanation perhaps it's not needed. And surely not every single forum needs description text - it just starts to clutter things up and creates a lot of scrolling to see the list of forums.

<strong> is perfectly fine, it's purpose is not to bold the text, that's just how browsers choose to display it's intended purpose (to give an element strong emphasis).