Jump to content


Alan

Member Since 19 Nov 2007
Offline Last Active Yesterday, 06:30 AM
****-

#2247306 A proposal toward improving IP.Board security

Posted by Alan on 28 March 2012 - 04:29 PM

In terms of password security specifically, yes, but in my experience the actual password is actually rather insignificant in terms of possible attack vectors. Keylogging, hijacking [notably RDP/RAT], and especially account recovery have all proven to be a far larger problem, and each one either reads off or bypasses the need for the password altogether. Account protection in my opinion should address not only cases where accounts are being attacked through the site, but also cases where mistakes on users' parts lead to an attack on the site. Any compromised account is a means toward even more trouble.


When you start talking about key loggers and the like the list of attack vectors becomes endless. I don't believe that it should be IP.Boards job to protect your members from every possible potential account compromise. IP.Board should be providing the basic tools to cover the main attack vectors (remote brute forcing and stolen databases), and then IP.Board, and us as forum admins, should be educating our members on how they can prevent getting their account hacked. Don't click strange links in emails, don't give your forum password to anyone, things like that.

You have to expect that a certain percentage of accounts will be hacked and plan accordingly by limiting the amount of damage a hacked account can do, allowing a member to easily recover a hacked account, and ensuring that whatever damage is done (in the case of moderator / admin accounts being hacked), can be un-done in the least destructive way.

IP.Board already addresses online brute-force attacks sufficiently in my opinion, although it does use a temporary locking mechanism which you seem to dislike.


I'm not a fan of the locked account mechanism because it's unnecessary. There are better options than blocking a legitimate member from using your forum for 15 minutes because someone tried to guess their password.

A fair point regarding international implementation. I'm honestly not sure what complications might arise, though to my understanding SMS standards are international. As long as the message can get out onto the phone networks, the rest should be irrelevant. Your concerns regarding maintenance and administrative setup are probably not significant--the most probable setup I can think of is having a single [okay, or redundant] node hosted at IPS itself responsible for dispatching the keys. Pricing is irrelevant, as only SMS is involved and most providers offer unlimited texting for a flat monthly fee.


To send a SMS from your forum to a user, you have to use a SMS gateway. They all vary in price, and they all cover different parts of the world (some only send to USA numbers, some to all or Europe, some worldwide, etc). But the common factor is that they all charge you to send a SMS through their gateway. If IPS where to host a SMS gateway themselves, they would be charged by their upstream gateway to send SMS messages, so IPS in turn would pass the costs on to us, either through an increased licence fee or as an add-on service. Either way, you can't just hook your mobile phone up to your forum and have it start sending messages for free, someone has to pay for it :smile:

As there are so many SMS gateways available (14+ million from a quick google), IPS would need to pick one or two and develop around their APIs. As those APIs evolve, and change, and companies merge and shutdown, IPS would need to constantly update and test their SMS sending code.

If they where to go down the two-step authentication route, I would much rather they do something along the lines of the Battle.Net Authenticator - http://itunes.apple....d306862897?mt=8

Blizzard use it as a two-step login system for their games and it works great. It's just a simple app to download to your smartphone (they also used to sell physical authenticators, not sure if they still do). It would cut out the SMS gateway hassles and IPS would have much more control. It does of course limit itself to members with smartphones.

...First, in the event of a compromise, there is a huge pressure to quickly gain control after discovery. You probably don't know how it happened or how far it may have spread--the ability to lock all of your staff out (or particular groups) until you can establish the situation and verify identities would be immensely helpful.


I would have thought that the best option in this case would be to shut down the forum completely while you figure out what has happened, and how to recover from it? I'm not sure why you would want to keep your site online after it has been compromised.

In my opinion, security is by far significant enough to warrant core inclusion, especially in this case. The cost of development for such a thing is fairly low, probably only a couple hours depending on how extensive the implementation is. The benefits are that every single IPS-powered community is able to improve their own security, potentially drastically.


Although the final code might look like it only took an hour or two to write, the reality is far different :smile: A feature like this, which impacts every user on every forum needs a lot of discussion to start. How should it be implemented, were should it be implemented, how will it affect existing users, what about password changes for existing users, what about 3rd party users, via Converge or social networks, what happens to existing passwords if the admin changes the rules a week later. All of these things, and more, need to be discussed by the IPS developers, then written plans need to be made to document it all, then someone needs to start working on the implementation. They may end up with 200 lines of perfectly crafted code but to get to that point they probably wrote 2,000 lines of awful buggy code and refined the hell out of it :smile:  Then it needs to be tested against every possible item that was brought up in the planning stage, probably via unit tests but also with manual testing.

So whilst it looks to us like someone knocked out a bit of code in 2 hours, the reality is that it took an IPS developer a week to plan, implement and test :smile:

By some means, an administrator loses control of their email account--or maybe they registered with an old email that was since deleted and can be re-registered. [Yes, I've seen it happen.] By means of a simple recovery request, the person who once had only an email account suddenly has full access to the entire community and even the Admin CP.


It's an interesting situation, it has never occurred to me that something like this would happen. Does having this option then open up other admins to social engineering attacks? It would be simple for me to create a hotmail account under the name of one of your moderators, find the stupidest looking admin I could, then email them pretending to be your mod and asking for a password reset.

I've a feeling that having a human link in the reset chain could cause a lot more problems than it would solve.

Staff members are people who are plugged in and almost certainly know other staff members well regardless. In the odd case that they do somehow lose their password, it is far preferable to have them go to another administrator and be personally vetted in order to regain access.


Would they personally vet them though? These are the same people that don't bother to update their email addresses or use strong passwords. I've a feeling that most admins would either ignore an email asking for a password reset or just blindly do it when presented with a well-forged email.

...Although yes, that information is most likely also logged by other means, in my experience it is far less accessible if even accessible at all. In our case, our servers have always been managed for us, and even if the access logs are available, there's simply too much volume to produce much useful information.


Is this just a case of not using the right tool for the job though? Many years ago I worked as Server Operations Manager for a managed hosting company in the UK and we wrote a bunch of tools that allowed us to quickly, and visually, search, and extract information from log files. Our servers got hacked daily so we put a lot of effort in to writing the tools we needed to make sure our customers could recover quickly.

This is definitely an interesting topic, a discussion on how to improve security is always a worthwhile one :smile:


#2247238 A proposal toward improving IP.Board security

Posted by Alan on 28 March 2012 - 02:28 PM

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:

  • Increasing minimum password length to 7 characters, or making it configurable.


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.


  • Removing the upper bound on password length, or increasing it beyond all practicality. (1)


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.


  • Converting to or providing the option of a time-expensive cipher for password hashing, such as Blowfish/bcrypt. (2)


Agreed, see above.


  • Implementing an optional two-step authentication process via SMS. (3)


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.


  • Providing a means of invalidating all system passwords and sessions, on a global or per-group basis. (4)


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.


  • Adding the ability to opt groups into tighter mandatory security policies. (5)


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?


  • Disabling account recovery for any group with moderator or administrative privileges.


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


  • Expanding administrative logging, and removing the ability to delete those logs. (6)


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 :smile:


#2126265 Add an id attribute to the ACP dashboard graphs div

Posted by Alan on 21 June 2011 - 01:10 PM

The div I'm talking about is
<div class='center' style='padding: 1px;'><img src="{$this->settings['base_url']}module=system&amp;section=charts&amp;days=7" alt="{$this->lang->words['reg_trends_chart']}" style='width:98%;' /></div>

I'm fiddling around with changing that graph using the Google Charts API and it would make my life a lot easier if that <div> had an id attribute :)

At the moment I rely on it being the only <div> on that page with the 'center' class which isn't ideal for obvious reasons.

jQ('.center').attr('id', 'cit-db-chart');
jQ('.center img').remove();

Ta in advance :)


#2123842 Skinning easier in 3.2? how?

Posted by Alan on 15 June 2011 - 02:10 PM

I honestly don't mean to be rude, but none of those replies help. Can anyone please help me with my original question? Thanks again ahead of time. :sad:


Not sure if you can see the blogs as an inactive customers or not but Matt posted a blog entry and video describing the new WebDav system and what it does / how it works - http://community.inv...e-skin-editing/


#2109111 3.2 Poll

Posted by Alan on 07 May 2011 - 02:43 PM

I don't really have an opinion one way or the other but "wall" always sounded silly to me. Why would I stick messages on to a wall? I might stick them to a pinboard, or whiteboard, or even in a box of some sort but I'm certain I've never pinned a message directly on to a wall :)


#2051413 Add confirmation prompt when deleting support requests (ACP)

Posted by Alan on 03 December 2010 - 12:11 PM

At the moment it's terribly easy to accidentally delete a support request when viewing it, particularly with the button being next to 2 others that are frequently used.  My suggestion is to add a confirmation prompt of some sort there to prevent us from destroying tickets by mistake :)


#2047329 Please enable attachments in the IPS tracker

Posted by Alan on 24 November 2010 - 11:00 AM

I noticed today that you can add attachments to reports in the IPS tracker in the IP.Board section.  Any chance you could also enable them in the other areas (the IP.Downloads and IP.Nexus trackers don't allow them, can't say for sure about the others).  Would make uploading screenshots much easier :)


#2046945 Let's be honest-- It needs some work.

Posted by Alan on 23 November 2010 - 05:06 PM

WOW! Thank you. Could you give me the exact field formatting using this solver: http://dx.doi.org/ (doi id here)


Sure thing, for the "Field Formatting" box, the following should work:

<a href="http://dx.doi.org/{value}">{value}</a>

If you wanted the DOI page to open in a new tab/window you could change it to:

<a href="http://dx.doi.org/{value}" target="_blank">{value}</a>

Any problems just let me know :)


#2046663 Kudos for the improvements in the latest version

Posted by Alan on 23 November 2010 - 08:45 AM

Just wanted to say thank you for the improvements in the latest version of IP.Content, I've been working with a couple of custom databases today and some writing some PHP blocks to pull them both together and things like textural keys is saving me so much time. No longer do I need to do a couple of queries to figure out what the table name / field_id's are going to be when they're installed on another site, I just pull the info straight from the cache and get to work :)

Not to mention the database templates, writing those just became a whole lot easier as well :)

Keep up the good work Brandon and Co!


#2003198 My "vision" of the perfect IP.Downloads UI

Posted by Alan on 10 August 2010 - 09:54 AM

For a while now I have wanted to design some mockups of the IP.Downloads user interface that I've always wanted and now I've finally got around to it :)

There are 4 mockups, category list, view category, view free download and view paid download, I've linked to the images below rather than include them in the post as they are rather chunky.


Category List - Mockup: http://nexus.forumin...tegory_list.png

Starting with the category list itself, there isn't much change here (imagine that it uses the standard IPB alternating cell colours), the only real change is the removal of the Latest File column.

The major change is the addition of the sidebar blocks.  The first is a featured download (configurable by admins), this featured download is from all categories.  The second change is the Latest / Popular / Rated tab box.  Again, this would pull file info from all categories.


View Category - Mockup: http://nexus.forumin...ew_category.png

Starting with the file list, it now includes a snippet of the description to fill up some of the blank space that was there before.

The author / etc details have been moved to a single column (again, assume that it uses the standard IPB alternating cell colours), this column could also include custom fields, for example, it could include the required IP.Board version for addons here on the IPS website.

This page also includes the Featured / Latest / etc blocks but this time they are pulled from the current category rather than all of them.


Viewing Free File - Mockup: http://nexus.forumin...w_free_file.png

All of the file information has been centralized in a new box to the left of the page, with the right box now only being used for the long download description.  File download links are now provided directly in this box rather than going to a seperate page, and it also provides social bookmarking links to help authors share their files (and get more traffic to your forum).

The screenshots are located below this box (those white squares with a cross through it are supposed to be screenshot thumbnails :))

On the right hand side of the page, you have the file description box, below that is the add comment box.  I've put this at the top to save people having to read through tons of "Thanks!" replies before they add a comment of their own.  Below that are the comments, these would be full-featured replies (aka, IP.Board replies) that support attachments, show the usual postbit, that sort of thing.  This also means that seperate support topics are no longer required.


Viewing Paid File - Mockup: http://nexus.forumin...w_paid_file.png

The only real change here is the additiona of the price and the Purchase button rather than download links, other than that, it works exactly the same as above.


Here's hoping that a few of these changes make it in to IP.Downloads one day :)


#1995337 Custom fields can change price of item

Posted by Alan on 28 July 2010 - 11:46 AM

I'd love to see the option for custom fields to be able to increase/decrease the price of an item.

For example, I am selling a T-Shirt that comes in 10 colours so create a custom field dropdown with the 10 colour options in it.

2 of the colours are super-special-expensive-tinted-with-real-gold colours so I'd like the option to increase the price of the product if the user selects on of those colours from the custom field dropdown.

Another example would be the number of years warranty they want with their product, 1 year costs $20 extra, 2 years costs $30 extra, etc.

Just an idea for a future version :)


#1979529 Reply to PM Notification email

Posted by Alan on 29 June 2010 - 01:49 PM

He wants users to be able to reply to the New PM Notification emails they get and for IP.Board to automatically add it as a reply to the PM in question.

Hopefully the new incoming email API will make things like this possible.


#1951647 Clarification on IP commerce > IPB ad management incorporation

Posted by Alan on 11 May 2010 - 02:47 PM

We thought about it, but decided to leave it out of 1.0 to gauge how much interest there is in this sort of thing.


Consider this a +vote from me - I'd buy the product just for this feature :)