Lewis P

Just use the difference exports located in Lewis P's signature.

Lewis P, on 23 May 2012 - 11:32 AM, said:

There will be a new feature in IP.Nexus 1.5 that will prorate your costs based on the date you actually do renew to match the others.

So like:

Today is 15 May and the Suite has a renewal date of 15 July. You choose to renew an expired IP.Gallery today at $10.

• $10 / 180 days (6 months) = $0.056 per day
  
• It's 60 days until the suite renewal (15 May to 15 July)
  
• 60 * $0.056 = $3.34

So you would be charged $3.34 to renew IP.Gallery today and the remaining balance of your $10 payment ($6.66) will be applied to account credit so it will be used for the next invoice on your account.

Edit: changed explanation to clarify.

Reference our blog entry this topic is referring to...

This topic explains the formula we are using to calculate the renewal dates when we change the license structure. For general feedback or questions on the license structure as a whole please create a new topic.

Here are examples on how we would recalculate renewal dates and such.


Standard License with apps

• IP.Board Standard License expiring 1 June 2012
  
  • IP.Gallery expiring 1 July 2012
    
  • IP.Blog already expired

IP.Board has a 6 month renewal rate of $25 and Gallery has a renewal rate of $10. This means that if IP.Board's days are worth 1 then IP.Gallery's days are worth 0.4 ($10 / $25). Assume today is 15 May 2012 so IP.Board has 15 days of credit and IP.Gallery has 45 days.

So now we have to calculate the equivalent days. We do IP.Gallery's 45 days * 0.4 = 18 days equivalent credit to IP.Board. It is 15 days between today (15 May) and IP.Board's expiration (1 June) so therefore we have 15 + 18 = 33 days of credit to work with.

Next we have to sort out how to apply those 33 days of credit. We are altering the renewal dates of IP.Board at a factor of 1 and IP.Gallery at a factor of 0.4 so 1.4 days of credit to keep everything active. Taking 33 / 1.4 gives us 23.57 (24) days of credit from today's date. So this results in 24 days from today (15 May):

• IPS Community Suite
  
  • IP.Board new expiration of 9 June 2012
    
  • IP.Gallery new expiration of 9 June 2012
    
  • IP.Blog remains expired

Another example:

• IP.Board Standard License expiring 1 June 2012
  
  • IP.Nexus expiring 1 July 2012

This case is a bit different as IP.Nexus has a higher renewal rate ($35) than IP.Board so the weight is 1.4. However, the formula is the same:

IP.Nexus 45 days * 1.4 = 63 days resulting in 78 days of credit from today (15 May). Again adding in the weights gives us 2.4 so we then do 78 / 2.4 = 32.5 (33) days of credit:

• IPS Community Suite
  
  • IP.Board new expiration of 18 June 2012
    
  • IP.Gallery new expiration of 18 June 2012
    
  • IP.Blog remains expired

Business License

For business licenses we will add in a new package type called "Priority Support and Service" or similar that will be an addon package to the Suite license.

Legacy Licenses

Lifetime license will change to:

• IPS Community Suite
  
  • IP.Board (Legacy: lifetime license - no extra services - ticket support included) No Expiration

If a Lifetime license holder as addons they will be recalculated using the same formula.

Perpetual license will change to:

• IPS Community Suite
  
  • IP.Board (Legacy: perpetual license - no extra services - ticket support available on renewal) Expiration date caries over using same formula

IP.Board/Gallery/Blog bundle will change to:

• IPS Community Suite
  
  • IP.Board with current expiration date
    
  • IP.Gallery with no expiration
    
  • IP.Blog with no expiration

General renewals and new purchases

IP.Nexus 1.5 supports prorating purchases so when you add/renew a new application on the Suite your price paid will be prorated so renewal dates remain the same.

You will still be able to cancel renewals on specific products so, as an example, you bought IP.Gallery but decided after a while you didn't use it you can cancel that renewal yourself or reactivate it later if you change your mind.

In 3.3.2, a new Privacy Policy link was added.  But unlike the similar Guidelines setting, we don't have an option to link to an existing Privacy Policy page; we can only enter in Privacy Policy text and give a new title.  For those of us who already had a Privacy Policy page, please give us an option where we can link to it instead of having to copy the text into this new setting.

Yes Android will also be able to push out custom images. It will be designed a touch differently of course so you will have separate sections for Android and iOS customizations.

Please add a new status in the tracker for patched issues. Sometimes the developers will post patches in the tracker for big issues. With the release of 3.3 there were a couple of patches posted (Reputation count showing as 0, super moderators cannot warn users, the moderating team page fatal error). These types of fixes don't exactly fit in with KB articles, but their patches are pretty important to people. Instead of using a "Fixed" status if you could add in a "Fixed with patch" status or something similar that would be helpful for anyone to come by and filter the results and apply the latest fixes instead of having to wait until the next release.

Browsing through the technical support board regularly I see the same things pop up over and over and the answer is to always link to the patched issues. At the very least they'd be easier to find with this filter so that I can link them easier. I don't save them or anything, I just search for them using the right keywords, but not everyone knows to do that.

I recently posted a feedback topic regarding the vulnerability of IP.Board's password hashes to a particular type of attack. Although the discussion proved to be informative, little was offered in the way of practical solutions. After several days of reading and consideration, I would like to revisit the subject. I've created a list of what I think are practical suggestions, addressing my earlier complaint as well as every other shortcoming in IP.Board's security that came to mind. All feedback is welcome, and I hope these will be considered seriously.


Looking at use cases regarding security, we find two different views: the user, and the owner. In general, the user will want to do what they always do. In its simplest form, this means not having to create some password conforming to complex requirements that they will never remember anyway.

On the other side, the owner and staff want assurance that unauthorized users will not be able to gain access to confidential areas of the site. In the event that that does occur, they want to know exactly what transpired, as well as assurance that any stolen data will not lead to further security problems for users or the site.

Frankly, IP.Board is currently rather pitiful in this regard. There are many measures administrators can take toward enhancing site security, such as htpasswd protection of administrative areas, or custom and 3rd-party login methods. However, relatively little is done to facilitate the simple implementation and use of effective security practices.


In the interest of balancing user and administrative interests as much as possible, and considering what is actually feasible, I propose the following changes.

• Increasing minimum password length to 7 characters, or making it configurable.
  
• Removing the upper bound on password length, or increasing it beyond all practicality. (1)
  
• Converting to or providing the option of a time-expensive cipher for password hashing, such as Blowfish/bcrypt. (2)
  
• Implementing an optional two-step authentication process via SMS. (3)
  
• Providing a means of invalidating all system passwords and sessions, on a global or per-group basis. (4)
  
• Adding the ability to opt groups into tighter mandatory security policies. (5)
  
• Disabling account recovery for any group with moderator or administrative privileges.
  
• Expanding administrative logging, and removing the ability to delete those logs. (6)

Implementation of most or all of these items would greatly enhance protection for all users. The result would be a hardened and more flexible environment that would appeal to prospective owners from many markets. This move would also serve to place the IPS Suite on the forefront in security, well beyond all competing products.

Footnotes

• On principle that users should not be unduly restricted (if they want a long password, why not allow?), in addition to the line of thinking proposed by these authors: http://xkcd.com/936/, http://www.baekdal.c...urity-usability The only negative impact this could have is introducing the possibility of a collision when going beyond the entropy of the hash itself. With sufficient brute-force protection [see (2)], this is largely irrelevant.
  
• PHP provides the crypt() function, which includes support for the Blowfish cipher provided the operating system supports it, or (as of 5.3) integrated into PHP itself. Blowfish includes a configurable cost parameter, defining the number of iterations internal to the algorithm. A higher cost results in longer hash calculation time. c.f. http://php.net/manua...ction.crypt.php
  The rationale for intentionally using a time-expensive cipher is that generation and validation time is largely inconsequential. A delay of 300 ms or even 3 seconds to the user during registration and login is a transparent and infrequent cost. That same delay serves to make any form of brute-force or dictionary attack infeasible, simply on the grounds that it takes too long to generate the result of a single input to check them en masse in any efficient manner. In this case, we're talking about an increase in processing time of five orders of magnitude or more. For greater explanation, see: http://chargen.matas...ow-about-s.html
  Blowfish/bcrypt also has the added benefit that it is not easily adapted to GPU calculation. The nature of its operations would lead to total saturation of the memory bus/controller and greatly limit parallelism. An efficient cracking device could theoretically be created on an FPGA, but this is well outside the reach of most consumers. c.f. http://crypto.stacke...-bcrypt-in-cuda
  Interestingly, there is a newer proposed cipher called 'scrypt', which was designed explicitly to be secure against hardware [GPU/FPGA] brute-force attacks. To date, however, it has not been implemented in any form easily accessed by PHP. c.f. http://www.tarsnap.com/scrypt.html
  
• See Google's 2-step verification, or Facebook's 'Login Approval'. After login, a short validation key is sent to a pre-entered and verified phone number by SMS; the login IP can then be saved for some length of time if desired. The rationale for this is that even if passwords and email accounts are potentially compromised, a person almost always has their phone physically on them, nullifying any attempt by others to access an account. This should also be used in email/password changes, recovery, and ACP logins.
  The complication with this, naturally, is dispatching the actual SMS messages. This could be implemented at a low volume through email-SMS gateways, which are carrier-dependent, or through notifications in the upcoming iOS/Android apps. Alternatively, IPS could purchase a dedicated GSM modem and provide this as an additional service.
  
• In the event that a catastrophic failure of some sort does lead to hashes being released, there should be a straightforward way of ensuring all users of a group [IE, moderators or admins] are logged out and forced to change passwords. This could also be used as a means of forcing routine password changes, though less than ideal. It has the complication of potentially locking oneself out of the ACP.
  
• On a typical site, normal user security probably isn't a major concern any more than users are personally interested in their own security. Thus, users should be restricted as little as reasonably possible with regard to authentication. Anyone with power over other users, on the other hand, is a liability, and should be able to be held to stricter standards. These could include longer or more complex passwords, mandatory use of 2-step authentication [see (3)], or periodic password changes. Accordingly, users should be required to change passwords if moved to such a group.
  
• In the event of an Admin CP compromise, it is crucial that the owner be able to determine precisely what actions transpired. This could be either to the extent that actions can be seen with enough data that they can be manually reversed, or to the extent that any malicious action can be identified and investigated in further detail. At present, neither is the case. Significant areas of the Admin CP are totally unlogged, including settings, templates, language, permissions, importing/exporting/modifying resources, and the SQL Toolbox.
  Additionally, there is no reason why those logs should ever be pruned from the Admin CP. Our site of 10 years, with nearly 400k registered accounts, has only 75,000 logged admin actions. The ability to delete those logs only aids those who would want to hide their actions, and those are the ones you most certainly do not want to delete. If the option must be there, it would be beneficial to hide rather than delete the entries altogether. Like admin login logs, this should also include built-in prevention from deleting them through the SQL Toolbox, and potentially even the DB class.

Unfortunately, it's the nature of the beast. We make web-based software, so it naturally has HTML templates. We have a moderately speedy release schedule because that's what users expect from us, and when new features (or front-end bug fixes) are added, that usually means a template has to be updated. Sometimes these are major changes; we do our best to keep these infrequent. Usually they're minor changes.

In the case of 3.0, it was a major version upgrade which completely changed how internals worked. For 3.2, it was another big upgrade that was necessary to keep IP.Board modern. There was around a 2 year gap between 3.0 and 3.2.

3.3 should only require minor updates to account for bug fixes.

Silly Brandon, everyone knows that what shows up in the address bar is more important than what the rest of the browser displays.

IP.Board 3.1.x and Applications: End of Life Announcement

So that we can focus all of our development, support, and service efforts on the newest version 3.3, we are announcing the end of support (sometimes called end of life or EOL) for the following IPS software versions (and earlier versions):

• IP.Board 3.1.x
  
• IP.Blog 2.2.x
  
• IP.Gallery 3.2.x
  
• IP.Downloads 2.2.x
  
• IP.Content 2.0.x
  
• IP.Chat 1.1.x
  
• IP.Nexus 1.1.x

Technical support, installations, and services will end for these products on August 1, 2012. On that date all technical or service requests will be advised to simply upgrade to the most recent versions of the products. We will not force upgrades but will also not be able to diagnose issues or answer questions relating to the older software. Also, on that date, IPS will no longer address any new issues or bugs reported in the older software versions.

You are of course free to continue using these older versions if you wish but IPS will no longer provide assistance after the EOL date.

Security Updates

In the event an issue is discovered impacting the security of these older versions of the software, IPS will provide a patch posted in our announcements forum. We will continue to provide security updates for several months after the EOL date based on severity of the issue.

Internet Explorer 7 Support

We announced our plans to start phasing out support for Internet Explorer 7 in December 2010 and have been slowly doing so. As of this date, IPS will no longer support Internet Explorer 7. This includes compatibility modes in newer browsers.

So this is one that's been driving me nuts. While working alot of the times I remember part of the name of the template but not exactly what it's called or what category it falls under. This causes me to open up all of the categories and ⌘+F to find it; then I have to manually cycle through the results by clicking the next button.

I would really enjoy to see a more streamlined workflow which would look something like this.


As an example this is how xcode allows you to search through methods.

I created an install routine in one of my hooks to place some icons in every skin folder automatically, though it probably won't work for every server setup.

It is possible.


The code is free for use, by the way--I'd just appreciate some form of attribution if you do.

Or another type of fix. Which is probably harder.

If the image cannot be found in the skin folder, check master for it. Then try and load it. Otherwise 404 the image.

Yeah, they do appear in the rich editor, it doesn't appear to do anything in the standard editor which I usually use.

Thanks for bringing this up.

I am aware of the issue you reported and I fixed it that same day. We do take XSS seriously although we do take precautions against this type of attack. For those that don't know, XSS allows someone to inject malicious javascript code into the page HTML. This type of attack is usually used to extract cookies or to redirect the user to a page they didn't specify.

How IP.Board protects against XSS in the core

• We make use of HTTP only cookies in IP.Board, so the session, member_id and member_hash cookies are not readable by javascript. This drastically reduces the risk of XSS being used fake a session or to be used to log in as the user.
  
• We make use of IP address and user-agent matching to further reduce the ability of a hacker to fake a session or to gain access.
  
• We use a MD5 key that is unique to each user to validate forms that are posted (log in / log out / post reply / moderation tasks). This means that unless the hacker knows your MD5 key, they cannot force you to perform an action without your implicit knowledge.

These things work in the core to protect you against basic XSS attacks and means that any XSS attack possible has a diminished affect. You can still 'break' the page layout via XSS by manipulating the DOM and force alert messages to annoy users, but any real damage to your board is almost entirely superficial.

Now, we generally patch and release updates for any XSS spotted as soon as they are reported. In this case, however, the fix was quite involved. I actually re-worked how entities are encoded and displayed in IP.Board for 3.2.3 to overcome many different issues including this particular bug you posted. This means that the fix is very involved and would mean many different file edits that is almost beyond the scope of a quick security update.

When I fixed the issue and replied to your bug report, the release of 3.2.3 was only a few days away. However, we decided to delay it for a few more weeks to really iron out all the reported issues. This has meant that the fix for this issue has been pushed back with the release but up until very recently it was not a published attack and as mentioned in this post, the affect is greatly diminished.

The fix has been in 3.2.3 Beta since its first release and we did mention that to you and I believe a few others who have asked. We are aiming for a full release of 3.2.3 early this week which completely resolves this issue.

We have continually monitored this situation and we do take security very seriously.