A proposal toward improving IP.Board security

[Ryan H.]

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.

1. [*]

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
http://chargen.matas...ow-about-s.html
http://crypto.stacke...-bcrypt-in-cuda
http://www.tarsnap.com/scrypt.html

[Purple Turnip]

I agree with everything except for minimum password length. I like to keep my password 1 character long (no hacker would EVER think a site's admin has a 1 character password!) Jk... ;)

Good suggestions!

[AnthonySh]

Fantastic set of suggestions, all backed up with sensible and workable ideas. I'd love to see these come into fruition, as security is important and at the moment could be improved. Whilst I'm not saying IPS software is insecure, I do think that it's always possible to improve security and take any steps that we can.

I'm a big fan of two-step authentication, and would personally love to see it in widespread use, especially if IPS are the ones to popularise it in community software :wink:

[Alan]

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:

[bfarber]

There is some intelligent and thoughtful discussion in this topic. :)

[Eduardo Bautista]

I agree with everything except for minimum password length. I like to keep my password 1 character long (no hacker would EVER think a site's admin has a 1 character password!) Jk... :wink:

Good suggestions!

Nice try with your reverse psychology, but I am still going to get into your site's ACP.

[Ryan H.]

When it comes to password security on a forum you're really talking about 3 possible scenarios:[list=1] [*]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.

[/list]

In terms of password security specifically, yes, but in my experience the actual password is 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.

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.

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.

Absolutely, and I noted as much in my proposal. I disagree that forum security in general is inconsequential--user security should never be taken lightly. I do see a distinction between what is appropriate for administrators with open access versus users who could hardly care less, though. That's why many of my proposals are either user-optional or entirely administrative in nature.

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.

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.

I honestly don't envision this as something entering widespread use, but its utility is absolutely invaluable. Again, the user/admin distinction: As a user, you could probably care less about security. As an administrator, you want to be absolutely certain under all circumstances that you have complete control over your account, even if some strange circumstances lead to your password being compromised. 2-step authentication provides that, because you have to get a code from your phone [in your physical possession] to authorize any login attempt. This has the side benefit of notifying you if anyone else tries to log into your account. And again, this would be totally optional for users--though preferably 'optionally mandatory' for staff. If you want security, this is close to the best you can get, and it wouldn't be difficult to achieve.

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.

A fair point, and certainly concerns that need to be ironed out and given more consideration than I've done. I have two principle concerns that I hoped to address with this point: 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. Second, in the event of a database leak, you may want a method to lock down accounts such that they cannot be accessed with the potentially-known password--the original owner should be the only one able to regain control. On the bright side, this would help avoid compromised accounts after such an event. On the downside, of course, this would be a huge inconvenience to everyone who then has to recover their account. Perhaps there is a better option that achieves the goal while avoiding some of the mess. Any ideas are certainly welcome.

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?

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 as a result.

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

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

In any system with multiple ways of getting into an account [password or recovery], recovery is almost invariably weaker. For that matter, many emails work solely on recovery questions, or perhaps are themselves linked to now-defunct email accounts. A failure anywhere in that chain breaks everything. 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.

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?

See my footnotes; I provided exactly such information. Our site of ten years, 400,000 users, 14 million posts, and two or three dozen administrators has accumulated only 75,000-some admin logs over its entire history. Scale accordingly. 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.

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.

Not as difficult as you expect, at least on a basic level. Although, yes, there's little that could be done about a manual SQL connection and queries, it would be trivial to add a check against table name in the database controller and SQL Toolbox--and like I noted, the admin login logs already do exactly that.

I appreciate your input.

I wish I didn't have so much experience with these problems. :unsure: Is our market segment atypical?

[PeterUK]

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

[Alan]

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:

[Sefket]

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

LOVE this idea. This is what I also posted about a while ago to, I think.

[Ryan H.]

Phew, this is ending up quite the lengthy discussion.

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.

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.

This is quite a tangent, but do you want a story to understand some of where I'm coming from?

custom modification

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

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

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.

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.

[Brett L]

The one thing that's great about IPB being viewable source is that you can edit it in your own way. You can make your board as secure (or unsecure) as you would like.


Just some quick tips.

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

You can simply run a query to change the hashes of everyone's passwords. Aswell as truncate sessions tables ect.

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

In the past what i've done run a query to change everyone's email address on staff to be an invalid email. EG just their member ID. '

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

You can remove the ability to delete logs under admin restrictions.
That said you need to understand that logs are not to be trusted as anyone smart enough will find a way to purge them. There is no way around that.

[Ryan H.]

You can simply run a query to change the hashes of everyone's passwords. Aswell as truncate sessions tables ect.

In the past what i've done run a query to change everyone's email address on staff to either be an invalid email. EG just their member ID. '

You can run queries to post, too, as it happens. Not really sure why we need all these interfaces at all; they just cause bugs.

[Brett L]

You can run queries to post, too, as it happens. Not really sure why we need all these interfaces at all; they just cause bugs.

Not quite sure I understand your response :). There are things in the ACP like the SQL tool box because some people find it really convenient and useful. Having one in its-self doesn't cause any bugs.

[Cyrem]

Regarding the SMS idea, I can see it's value in security. However it can also be a real show stopper. Some people simply will not want to give out their mobile numbers to verify their account. I wouldn't be suprised if registrations per day drop because of this. Even I would not register on a forum that wanted my phone number. Storing of phone numbers could bring up further privacy issues with users and turn forums into more valuable targets for hacks.

Such a feature would be passable for forums for webshops or forums run by large corperations, but I don't see how it is going to be good for any joe's forum.

[Matt]

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!

[Guest]

One thing to bear in mind with some of the security 'options' is that if the person breaks in and can run a script whether that is by ftp, or other chicanery most of the additional security is avoided anyway. SMS validation will be a barrier as they change numbers etc. Also, doing things like adding .htaccess for the admin centre is no barrier if they are able to delete the file and so on.

Once they are in and have access to the database/file information anything done front end wise becomes a bit irrelevant. Making the password length longer with a minimum, possibly with an option to expire old passwords and then trying to make sure your users don't re-use passwords across systems is the only real solution. And naturally the most important of all is that anyone with admin access must be forced to realise that they have to take password security seriously as they are the real way in fr these people most of the time.

Up until v4 aMember stored all passwords as clear text there a many thousands of installations and the act of clear text passwords in itself is not the security risk so long as access to the db is restricted. Not that I am saying we should do that!

[Alan]

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.

Not an ideal solution but if you were to change hashing methods, you could always hash the existing hash, then save that as the password hash. It does means you'd end up doing something like "crypt(md5(md5($salt) . md5($password)), $salt)" every time someone wanted to login though, and it would break every 3rd party script that does its own password checking against the IPB database.

[Cyrem]

Not an ideal solution but if you were to change hashing methods, you could always hash the existing hash, then save that as the password hash. It does means you'd end up doing something like "crypt(md5(md5($salt) . md5($password)), $salt)" every time someone wanted to login though, and it would break every 3rd party script that does its own password checking against the IPB database.

That is quiet a messy solution and probably will cause more problems than it solves. If any change in password hashing took place it would probably be in a major version like IPB 4/5 etc.

[PeterUK]

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.

What about an opt-in system for members (ie. they go to their User CP and opt their account in), using Google Authenticator, which is compatible with Android, iOS and Blackberry?

[Rimi]

Somewhat related to this topic. Thought I'd share this story.

I was just registering on a site. I enter my usual 6 character password that I use for everything that I don't consider to be important. The anti-spam measure was annoying as heck. It had a picture of a clock and you had to tell the time..thing is it looked like the clock had 6 hands. Anyway I got through that and clicked register and it tells me the password needs to be 8 characters long. So first piece of advice, if you're going to implement password requirements please list them on the registration page. Second issue. I was provided with a go back link which I clicked. My entire form was wiped out and I had to type my email and username again. Not a big deal but no unintuitive.

[Ryan H.]

Thanks, Matt. I appreciate the feedback.

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

It hadn't occurred to me that different bcrypt variants might pose a problem. Hard to find much info on the matter. PHP 5.3+ has Blowfish integrated, but it's not clear whether that's always used or only as a fallback. In any event, the suite supports 5.2 too, which would definitely be a problem.

As for changing algorithms, it's possible to do on a live system, but it's not particularly pretty. On login, check the form factor of the hash to determine whether it's old or new [or have some boolean to that effect]. If it's old, validate it under the former system, then generate and replace it with the new hash if it checks out. -Even so, you're right, you'll have users who don't log in for months or years, so the conversion never totally finishes. I suppose the best option would be to define some cutoff and simply wipe any old hashes still in the system at that point. Even then, maintaining the login methods in parallel is not particularly desirable. I can understand that.

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.

Fair enough. As PeterUK noted, I envision such a system as being opt-in, rather than mandatory on registration. I agree that making registration any more involved than necessary is undesirable.

Once they are in and have access to the database/file information anything done front end wise becomes a bit irrelevant. Making the password length longer with a minimum, possibly with an option to expire old passwords and then trying to make sure your users don't re-use passwords across systems is the only real solution. And naturally the most important of all is that anyone with admin access must be forced to realise that they have to take password security seriously as they are the real way in fr these people most of the time.

Once someone gets unfettered access, then yes, naturally all bets are off. The goal is to never allow them to reach that point. That's where policy and architecture improvements have their use. As for file access, that has protections of its own you can set up if you're on a VPS or dedicated box--use SFTP rather than FTP, and consider an IP access list on top of authentication.

[bfarber]

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

[Guest]

Once someone gets unfettered access, then yes, naturally all bets are off. The goal is to never allow them to reach that point. That's where policy and architecture improvements have their use. As for file access, that has protections of its own you can set up if you're on a VPS or dedicated box--use SFTP rather than FTP, and consider an IP access list on top of authentication.

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.

[Ryan H.]

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.

I agree, the hash is only a small way of addressing a much larger problem. It's totally irrelevant in all cases except where the database was compromised in one way or another.

The best way to counteract brute-force attacks beside increasing password entropy is to slow them down. Use a method that takes them a few milliseconds to calculate instead of a few nanoseconds [as with MD5 and SHA]. By doing that, you just increased the time to crack a single password one million times over. That's basically what I suggested for that part.

The other more practical change is to add something so that the password isn't the only piece needed to get into the account. That's where 2-step verification comes into play. It doesn't matter how strong or unique your password is in that case.