As the MyBB 2.0 development gains traction again — a joint effort of the Team and our technical Community — we are passing an important milestone in the area of the Project’s organization. Entirely new concepts, de-facto standards and unspoken rules, either improving the fluency within the Team or aimed at increasing MyBB’s maturity (and sometimes both), are being continuously brainstormed. We would like to share our progress so far in areas we are confident about.
PSR standards conformance from MyBB 2.0
World Standards Day / International standards day is celebrated internationally each year on 14 October. […] The United States held a 2014 U.S. Celebration […] on 23 October […].
Currently our coding standards are rather specific when compared to other projects in the PHP Community, and may be perceived unnatural (exhibit A: 1.8 development standards) — starting from 2.0, MyBB’s source will be fully conformant with PSR standards. While this means that we will be inevitably choosing a standardized side in one of the greatest arguments in the history of programming, which we have been avoiding for some time (exhibit B: 2.0 Dev Post #5), this decision will assure that our code preserves compatibility of coding style with other PHP projects and frameworks. This should lessen the confusion in Pull Requests and allow new contributors to adapt more easily.
Secure connections to *.mybb.com websites
A simple visit to any of our websites involves many platforms and servers: by connecting to our Documentation on docs.mybb.com, your requests go through our reverse proxy (currently provided by CloudFlare) to hit our Jekyll-powered website hosted on GitHub Pages from the Docs repository, whereas requests to the Blog you are reading this article on go to WordPress.com platform servers instead after following a similar path. Spreading our web presence in such decentralized manner has great advantages with independent availability being the most significant one, however maintaining them all becomes more complicated and introduces security risks with each addition.
In order to aid that, we have launched efforts to start enforcing HTTPS traffic to our websites and inserting security-related HTTP headers — although we don’t control external servers, we were able to set up the most important redirects and directives using the reverse proxy; these changes, combined with Subresource Integrity hashes for external content served on mybb.com and docs.mybb.com, provide a reasonable level of security given access limitations for any project that decides to set up their infrastructure in this fashion. If you happen to randomly browse the Chromium source code, you will discover that the mybb.com domain is now present on the HSTS preload list, making derived browsers enforce HTTPS upon first visit out of the box, helping our case a great deal.
Having control over the server hosting the Community forums and download Resources, we set up additional security headers that are now sent to the browser from both locations and our MyBB installation to serve cookies with the Secure flag, a feature shipped with MyBB 1.8.10. By using a MyBB plugin with a Node.js proxy server, external resources on our forums are now being delivered to users over a secure connection, resolving the issue of insecure content and enhancing their privacy by eliminating the necessity of downloading data directly from third party servers. Even when either one breaks, the Content-Security-Policy header will prevent insecure content from being loaded (the next major version of MyBB will make it possible to include all common security headers, as we will be aiming to eliminate obstacles like inline JavaScript).
You can take a closer look at the gritty details of our current setup here and here.
Team members’ PGP keys now available
The transition of our development process, now headed towards MyBB 2.0, largely impacts the organizational matters of the Project itself — one of recent preparations for an improved release management protocol that are easy to spot is the rollout of PGP keys that can be used to contact Team members, if you have a feeling that your messages sometimes have more recipients than they should (or if you’d rather be safe than sorry and use it out of principle, like we do). These can be found on our refurbished Team page that now also links accounts on social media, acting as backup channels of communication.
Packages integrity and authenticity measures
While keys and fingerprints present themselves excellent on our website, they won’t be used (only) for aesthetic purposes: we will start signing MyBB releases. Designated Team members will be able to submit a public key that will be added an announced on our website and and social media feeds for transparency purposes.
Further, while the hashing algorithm used for internal file verification and passwords in MyBB 1.8 is weak in today’s standards due to the codebase’s age, there is a lot of room for improvement when it comes to verifying the packages. If you’ve been paying attention to the release notes, you’ve probably noticed that we started publishing additional, stronger checksums for each release package as of MyBB 1.8.8. These actions are intended to provide webmasters with a degree of confidence when it comes to integrity of MyBB packages while still maintaining focus on the development of MyBB 2.
Vulnerability assessment with CVSS v3
We always have been trying to provide as much information as we could when it came to security patches after an update, however we were not quite satisfied with limiting the security issue index to a simple low-medium-high scale used in MyBB 1.x. MyBB’s RFC #9 has established one of major foundations of the security process, starting with MyBB 2.0: Each vulnerability fixed in given release will have a CVSS v3 score assigned, as specified in the Common Vulnerability Scoring System, V3 document. The 8 basic metrics will allow us and any third party user, team or organization to assess the exploitability, scope and impact of vulnerabilities and to adjust the rating by adding extra details within the same scale using Temporal and Environmental Metrics, allowing system administrators to prioritize and organize proper responses. For example, a SQL Injection vulnerability in the Moderator Control Panel could be assigned a score of 6.3 (Medium) comprising of base metrics CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L, all of which would be published in release notes of corresponding releases.
Spotlight on security research
Another significant part of the Project’s organization plans is to launch a Security Hall of Fame. Researchers reporting security issues and vulnerabilities, provided they follow responsible disclosure standards, will be placed on a dedicated list in recognition of their time and cooperation. In accordance, MyBB will promote post-incident analyses and write-ups, aiming at increasing security awareness and promoting community-based code reviews. To supply you with latest details and articles related to MyBB’s state of security, we have launched a dedicated, technical Twitter feed — make sure to follow @mybbsecurity to let us help you maintain a strong grip on your board’s security.
MyBB Blog 
My opinion is that unless you have security experts in the team, this all becomes quite confusing. CVSS is a complex model that is sometimes difficult to understand and apply (requiring quite a bit of work). You should have probably opted for STRIDE and DREAD classification systems which are much easier to understand and apply, especially for non-security experts.
I also don’t see how relevant it is for most users that you provide a digital signature of the original package. Why isn’t the checksum enough? An attacker could modify the release page and display the checksum of a modified ZIP instead – true, but I’d say most users, if not all, will overlook the digital signature of the original package and will not verify it against the hash of the modified ZIP. I’d say most overlook the checksum already…
PGP seems useless to me in this kind of environment as well.
Most of these measures look pretty to me but bring no effective value to the community IMO – at a cost. While I appreciate the effort at trying to improve the overall security of the project, these measures contribute little (in my opinion of course) compared to the overhead caused (the trade-off doesn’t sound nice to me).
It would be more interesting to use public key cryptography to provide authentication to the website where releases are handled (I assume server access already requires it). This would definitely ensure an attacker would have needed to compromise the computer of a team member in order to use their private key (the same doesn’t happen for passwords) – that or an attacker would require access to the server to whilelist other public keys.
Anyway, my two cents.
Thanks for your input.
CVSS will provide us with a clearly defined basis for choosing between low, medium, high and critical risk; the assessment is pretty straightforward and it shouldn’t slow down the process, especially that most CVSS factors are discussed internally anyway.
We’re aware that the PGP/GPG and CVSS signatures will not be used by average webmasters, however they may come in handy to security professionals and administrators that prefer validating that the software actually comes from the the MyBB Team. We’ll be aiming to satisfy these expectations while not bloating the release posts with too much technical information.
We also already take advantage of public keys to manage servers and monitor the security of all GitHub accounts with write access to our repositories (where e.g mybb.com and docs.mybb.com are generated from).
Thank god you finally moved from tabs to spaces 😉 I used to be a die hard tabber but after hearing a PSR talk I changed and never looked back.