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