Maxxius reacted to z1000-forum.de in Classifieds Extended Permissions
File Name: Classifieds Extended Permissions
File Submitter: z1000-forum.de
File Submitted: 21 May 2012
File Category: Commerce
Supported Versions: IP.Board 3.3.x, IP.Board 3.4.x
This hook adds permission settings for minimum posts and registration days(feel free suggesting your ideas about it).
Per package settings No template edits Full language support
Installation instructions:Log in to your IP.Board Admin CP and visit the System tab -> Applications & Modules -> Manage Hooks page. In the 'Install a New Hook' section, browse to the XML file included with these instructions and click Open. Once it installs this hook, be sure to enable it!
here to download this file
Maxxius reacted to Rod. in What is the status of making IPB better with SEO?
I've been a customer since 2000, and unfortunately I'm considering moving to another platform. IPB has come a long way and is by far the best looking forum software out there, hovered it's time IPB focuses on making their software search engine friendly. My traffic is serosulsly suffering due to poor optimization. I've been waiting years now for IPB to get seo right, but when is it really going to happen?
I'm giving it a few more months to see where things go. Its unfortunate that there are a plethora of negative info out there talking about how bad IPB is with seo.
It's time you guys focus your energy on making the forum more search engine friendly. You already have the best and nicest platform, now focus on seo.
Hope you guys take my feedback seriously, as I don't want to switch. However, I also need to consider the future of my site.
Maxxius reacted to Adriano Faria in Download: (SOS32) Admin CP Security Password
File Name: (SOS32) Admin CP Security Password
File Submitter: Adriano Faria
File Submitted: 06 Oct 2010
File Category: Modifications
This mod will add a 'security password' field to the Admin CP login page. The password can be changed or enabled/disabled through the ACP. For security reasons, when you update the password it will be converted to an md5() hash which is a long alpha-numeric string... To enter a new password just clear the box and enter it as you normally would.
IP.Board 3.3.X IP.Board 3.2.X
Specific Notes:Based on mod SE22-ACP Security Password 1.0, from Sean (Invision Modding), for IP.Board 2.2.X 4 files edits required - cannot be used on IPS Hosting.
Click here to download this file
Maxxius reacted to z1000-forum.de in Classifieds Push Ad
File Name: Classifieds Push Ad
File Submitter: z1000-forum.de
File Submitted: 09 May 2012
File Category: Commerce
Supported Versions: IP.Board 3.3.x, IP.Board 3.4.x
This hook adds the ability for users to push their old adverts to be displayed on top of the recent adverts list.
Push button for adverts Permission checks Settings per package
Installation instructions:Upload the content of the upload folder to your server. Log in to your IP.Board Admin CP and visit the System tab -> Applications & Modules -> Manage Hooks page. In the 'Install a New Hook' section, browse to the XML file included with these instructions and click Open. Once it installs this hook, be sure to enable it!
Don't have Classifieds? --> Download now: Classifieds
here to download this file
Maxxius reacted to -RAW- in -RAW33- Top Posters
File Name: -RAW33- Top Posters
File Submitter: -RAW-
File Submitted: 22 Apr 2012
File Category: User and Social Engagement
Supported Versions: IP.Board 3.4.x
This hook will add list on the side showing top posters on your board.
- enable/disable hook,
- choose which groups can see this list,
- choose how many members to show,
- choose top posters by day,week,month or overall,
here to download this file
Maxxius reacted to tonami in [Suggesttion] Follow a member (like Twitter)
I love Friends function of IPB, and I have a feeling that it's not really a "friendship", someone add you like friend and you just become friends! My first question is there anyway to require an approval when someone add friend as default function?
I think a function like Follow a member (become a Fan, a follower...) will make IPB much more social, so members can follow any update of people they follow. Also they can see who follow them. And a member when he add someone as friend, if not accepted, he still can follow him/her to see updates.
What do you think about this function?
Maxxius reacted to 3DKiwi in IP SEO - Options not to track visitors and keywords
Please give us the option with IP SEO not to track keywords and search visitors. On a medium to large site the result is thousands of pages of pretty boring results. Yes, some people might the information useful. I don't and I don't need my database bloated by an extra 10-15mb on this data.
The image here shows 1442 pages of results. That's just 8 days results as I manually ran a MYSQL query to delete results older than 7 days yesterday. The default for pruning these records is 35 days. I don't need to know this information. My server has Awstats and gives me more or less the same information. I don't need it twice.
Nigel / 3DKiwi
Maxxius got a reaction from Virgis in Download: Rage Comics emoticons
File Name: Rage Comics emoticons
File Submitter: Maxxius
File Submitted: 02 Apr 2012
File Category: Emoticons
There are 60 emoticons in total.
Icons are 30px in height (width varies).
Icons are in PNG transparent format.
How to use:
Step 1: Extract the .zip file.
Step 2: Go to your ACP, once there go to Look/Feel > Emoticon Management to upload them here via the four upload box's.
Step 3: Make sure you choose which emoticon set to upload them to (if you have multiple ones present).
Click here to download this file
Maxxius reacted to KevinMc in Support For IP.SEO?
I'll start simple.
What's with the lack of support with the IP.SEO forum? Don't you guys think it's important to the members, along with everyone else out there that's watching it, to support an application you develop? From the outside looking in, or from someone on the fence about making a product change, I'd feel this is crucial.
Maxxius reacted to bfarber in 3.3.1 release schedule? How is initial feedback looking?
IP.Board 3.3.1 will not be made available on a Friday. ;) We don't do that, as support is limited over the weekend.
Maxxius reacted to shaks in 3.3.1 release schedule? How is initial feedback looking?
Yeah, i jumped when i saw 3.3.1 running on this forum, but the client area shows only 3.3.0. Maybe it'll be available for download before the weekend?
I'd like to complete the upgrade before Wrestlemania 28 on Sunday. :sheep:
Maxxius reacted to Wolfie in 3.3.1 release schedule? How is initial feedback looking?
You two must be new to the world of software development. Even if you were to take 140 and add 75 to it to get 215, that's not too bad for an initial release of a new version of a product. Anytime several new features are introduced along with performance tweaks and other bug fixes, a number of new bugs are bound to pop up. So with there being under 100 (confirmed/fixed) is actually really good.
So in all actuality, this is one of the most stable 'main' releases there has been. With .1 then .2 and maybe even a .3, the number of bugs should drop drastically. The reason I said "maybe" a .3 is that with as good as it appears to be (so few bugs), I wouldn't be surprised if 3.3.2 was the end of the line for the 3.3 series. The developers did an outstanding job and we should give credit to them for such an accomplishment.
if you still think 215 is a high number, then go check out one of the veryBad competitors. I've heard how their 4.x series had well over 1,000 bugs when it was first released (in final status) and that's with 4.x really being 3.x, just repackaged. They actually took a stable product and created a massive number of bugs into it, instead of a complete rewrite, which then would have made 1,000+ bugs a bit more understandable for a 'final' release.
Maxxius reacted to Wolfie in IPB 3.1.0 features
Oh you foolish boy, you don't know how wordy I can be. ;)
I'll try to keep this short though.
ACP/Skin editor, make the left menu panel collapsible (like on the board index, the items on the right). Also, make the template names a fixed width to make it appear neater, but also can be minimized.
More ideas to come...
Time controls when posting. By this I mean start and stop times to post a new topic/post or have a topic pinned. When telling when to make a post, the start time would be when to post it, the end time would be a "delete" time.
Also, if a "bump" feature is included, automatic bumping (once every 24 hours after the topic has been bumped or had a post made to it), with a limit on how long it can be bumped after the last post inside the thread. Say 3 days as a default (for a particular forum), someone makes a topic and someone with bump powers enables autobumping, then for 3 days after the last post in that topic, the topic will get bumped every 24 hours.
Edit: Even more...
Be able to backtrack where you got +'s and -'s from (on posts).
Fixed "read" markers. Also, when a subforum of a subforum has a new post, have the green indicator thing of a bob turn on, so people know where to look. The main forum folder is sometimes lit (new posts) but none of the shown subforums are green, so you don't know if it's giving a false indication or not until you click that forum and then see the sub-subforums and see green indicators (unless it's another level deep, then you have to hunt for it).
Be able to have age/gender based criteria. With this, if someone sets their age or gender on the board, then they can choose to have that information hidden but can NOT change information itself. So an "Adults only" forum could be made or some other restriction and someone couldn't change their information to gain access to it.
If someone is a global moderator or is assigned as a moderator for a forum, then they are only affected by permission masks (ie, not age nor gender).
Be able to assign someone (or a group) as a forum owner. Forum owners as given special permissions as the can recruit people to be moderators of that forum (and only that forum). To keep it simple, the difference between owners and moderators is that owners can promote/demote people for that forum. They cannot create their own forum or subforums, that has to be done by someone with ACP access.
(Still more to come!)
Maxxius reacted to Matt in A proposal toward improving IP.Board security
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!
Maxxius reacted to Ryan H. in A proposal toward improving IP.Board security
Phew, this is ending up quite the lengthy discussion.
That's a nice ideal, Alan, but it doesn't scale. I could be mistaken, but I assume you don't have much experience working with large communities. I can harp on security all day long, and I've done so with our staff and users many times in the past. The problem is that it's a losing game--there is always something that can go wrong, some mistaken that can be made, and it only ever takes one.
I administrate one of the largest communities for one of the largest MMORPGs on the net. That in itself is a big enough deal, but it also means we play host to many of the game's organized clans (who don't always play nice), and occasionally become a target to people wanting to steal in-game accounts or even just cause mischief and mayhem. Over the years we've dealt with weeks-long DDOS attacks, influxes of phishing and spamming attacks targeting users and staff alike, IP scraping [to DOS flood and force-disconnect competing players] which I created a to address, and many more compromised accounts than I care to count. On the whole, most issues were fairly isolated and easily managed. We have actually become quite proficient in handling our own security--or had, I should say. A number of complications arose when we switched to a custom login system to integrate with our now-parent company's database, but that's another matter entirely and not one for me to get into. Several months ago, back in October, a new group surfaced that went above and beyond all of that. Not particularly innovative, but intelligent enough to find their way around. They systematically targeted every single major fansite for this game, always finding some weakness to exploit--an SQL injection in this one, unpatched software in that one, an open account in this other. Each time, they would dump the database, make a big deal about it and then sell it to the highest bidder [or use it for their own purposes]. Endless phishing emails were sent to anyone caught up in it trying to steal game accounts, the information was used to abuse the in-game account recovery system, and they most likely ran all of those through some brute force scheme as well. In at least one case I know of, they not only did that but also dropped the entire database and deleted all backups. The site basically started over from scratch. We were aware of this as soon as the group surfaced, and we made certain to harden everyone and make sure everyone was on board. We survived the wave of attacks in October and November, and never had anything more than a minor news feed defaced for a matter of minutes. If I remember correctly we were the only site to do so, sans one on the Wikia network and a variety of smaller sites. We heard nothing about them for months afterward, until just two weeks ago they managed to compromise a junior admin's email, recover his account, and escalate to a root admin account [which there were only two of at that point] thanks to a single error in our configured ACP restrictions. Cue database dump, mayhem, and seemingly endless aftershocks. To be expected.
... All that to illustrate my point: Even if you're extremely careful about being security conscious and making sure everyone follows good practices, eventually something is going to go wrong or the one weak link will be found. All it takes is one for the whole system to crash down. Yes, in an ideal world, everyone will have perfect passwords that are unique to every site and they will never fall prey to a malicious link or exploit or have any account fall into the wrong hands. But that doesn't happen. More to the point, we can prevent any one of those things from turning into a disaster, and it wouldn't be very difficult to do.
That's why I posted these proposals. It's not for our sake, really--we already lost, and our login handler means the biggest ones probably wouldn't affect us anyway. But they absolutely would benefit every other community out there that has to deal with any of the issues that we do on a regular basis.
Once again, that's simply not an acceptable conclusion for a site of any notable size. Damage control is an essential feature, but it should be your absolute last resort, not your first. Use any means possible to prevent any situation from ever reaching that point in the first place.
Perhaps you know way more than I do about the matter, but I really don't think it's that complicated. A GSM modem (http://www.nowsms.co...-is-a-gsm-modem) allows any computer to communicate over mobile networks. That includes sending SMS messages, given the necessary integration. Once the message is on the network, the carrier handles all of the work of actually routing it to its destination--no gateway or fancy handling is necessary here at all. And again, since it's normal SMS under normal usage [with a real SIM card and plan], it shouldn't cost an exorbitant amount.
Regardless, yes, an in-app solution is also a possibility, and I mentioned that as well in my initial footnotes. It probably wouldn't be difficult to work into the iOS and Android apps already under development. The downside is, of course, that you then need an iOS or Android device to actually use the two-step login, whereas virtually any cell phone can receive SMS.
Again, an issue of scale. A major site does not simply go offline, especially given an issue that is basically administrative in nature. While the event certainly can impact users in the end, we would gain nothing by refusing them access to the site, and stand to lose quite a bit. In the event that the login or template system were tampered in some way, it would of course be something to strongly consider. We spent most of the last two weeks without administrative access until things were ironed out--we did not go offline.
I've worked in professional web development for several years now--I understand these things. :tongue: I suppose I did low-ball the amount, but I don't think it's so bad as you suggest.
Social engineering is absolutely a problem, yes. In our case, we have enough history and our admins are smart enough that it's not a big deal, but it's still something we have to consider [now more than ever]. Most of us stay in touch through other means [IM, IRC, Facebook, phone, ...], which provides a more reliable channel of communication. If there is any question, it'll be passed up the chain to myself or another senior admin to handle. Asking a pointed question or two regarding things long past and checking against IP history does a good job of keeping things straight. We also use a probationary policy for all returning staff (for multiple reasons, but partly this) which means they don't get any access back until they've been involved for a while.
That's a problem with your staff, not the software. Provide the means; it's up to people to make it work for them. I can say with confidence that it would not be an issue for us, but that's hardly important.
I don't think 'log analysis can be implemented at the server level' is a valid justification for not providing suitable logging in the software itself. IP.Board already has the functionality engrained--it's just somewhat neglected.
As far as whether there is actually any justification for implementing tighter security, I say an unequivocal 'yes.' Good enough does not work when it comes to security, especially if 'better' is not prohibitively complex or expensive. Here, I think it is not. The development costs for most of my suggestions are fairly limited--the benefits are not.
With a little effort, IP.Board could easily move from having acceptable security measures to having stellar security measures. That means secure communities, happy customers, and an incredibly attractive potential marketing point. Although I'm not by any means an enterprise or high-profile client, I suspect 'cutting-edge security' would go a long way in moving the IPS Suite up their list.
Maxxius reacted to Alan in A proposal toward improving IP.Board security
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.
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.
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.
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.
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:
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.
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.
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:
Maxxius reacted to Alan in A proposal toward improving IP.Board security
When it comes to password security on a forum you're really talking about 3 possible scenarios: 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:
[*]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.
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)
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. 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. Agreed, see above. 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. 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. 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? What's the use-case for this one? I'm not sure why you would want to do this. 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:
Maxxius reacted to Ryan H. in A proposal toward improving IP.Board security
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, 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. 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: 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. 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. [*]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. [*] 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-usabilityhttp://php.net/manua...ction.crypt.php