MyBB Community Forums

Following best security practices, users' passwords in MyBB are not stored anywhere, but are verified using an irreversible value — a hash of the password.

This approach makes them unreadable in case of a data breach — an attacker could otherwise gain access to live forum accounts, or take advantage of passwords re-used across different services. The only way around for them is to guess potential passwords and compare their hash values to the ones found in leaked database contents. Unlike the online login form, access to actual hashes makes guesssing original values much faster.




Because MyBB 1.8 uses a MD5-based algorithm that makes this kind of attack too easy (billions of MyBB hash guess attempts per second), an upgrade is planned for MyBB 1.9. Better suited, resource-intensive algorithms will be added to make repetitive attempts impractically slow (but without introducing noticeable delays during individual login checks).



In the meantime, forum administrators can use the DVZ Hash plugin to make MyBB save passwords using modern algorithms, and to secure existing password hashes.



Setting up DVZ Hash

First, make sure the server is running PHP 7.0 or newer. PHP 7.4 or newer is recommended to take advantage of all features. It's also a good idea to create regular backups that can be restored in case something goes wrong.

Choosing a Supported Algorithm

In most cases, forum administrators should pick one of the two standard options:

• bcrypt
  
  bcrypt is a less recent and widely used algorithm with a customizable cost parameter — higher numbers will increase computation time exponentially.
  
  If unsure about algorithms and parameters, bcrypt with a cost parameter of 12 is a good start.
  
  
• Argon2id
  Available on servers with PHP 7.3 or newer.
  
  Argon2id can be set up to take advantage of multithreading and large amounts of memory, slowing down brute-force attempts on specialized hardware. This algorithm can be adjusted using 3 options:
  
  
  • threads, the number of threads to use in parallel — bigger numbers will decrease computation time (up to a certain point, depending on the number of processor cores available on the server),
    
  • memory, the amount of memory to use, in KiB — bigger numbers will increase computation time,
    
  • time, the number of operations performed using resources declared in previous parameters — bigger numbers will increase computation time linearly (used when memory cost cannot be increased any more)
    
  
  The parameters should be chosen in the same order: first find the optimal number of threads and increase memory until acceptable memory usage or execution time is reached. To keep memory usage the same but extend computation time, increase the time parameter.
  
  Note: the plugin's settings accept the memory value as a power of 2 (2ⁿ; e.g. 16 would result in 65 536 KiB).
  

Choosing Parameters

The execution time is hardware-dependent: identical parameters may result in different computation times, depending on the server. Therefore, it may be beneficial to measure performance individually to strike a balance between usability and cost of brute-force.

Server Resources

As long hash computation may cause other, simultaneous requests from other visitors to be processed more slowly, the algorithm parameters may have to be decreased to account for this. On forums with high activity, the target computation time can be divided by the number of requests containing user passwords that the server should be able to serve in parallel, without extending waiting times.

E.g. for Argon2id, the number of used threads and memory should allow other requests to be processed, and other system software to run smoothly.

Resulting Delay for Users

It's generally recommended to keep the computation time of a single password hash between 0.1 s (100ms — perceived by most as immediate response) to 1 second (1000ms — keeping most users focused).
Note that MyBB's sign up and login pages may take more time to load when compared to the hash computation time alone, and the parameters can be adjusted to keep the total time within an acceptable range.


To find optimal parameters, use the Benchmark tool (available on PHP 7.4 and newer) in the Admin Control Panel's Tools & Maintenance → DVZ Hash → Benchmark.




Choose the algorithm and parameters (or a range for one of them) to test, and use values that result in desired execution time by comparing the average x̄. If some parameters exceed the server's resource limits, or the measurements are taking too long, an error may be shown and the parameters will need to be lowered.

Example experiments that can be run to find best parameters:

• bcrypt
  • set cost to 4..14 to check times for costs from 4 to 14
    
• Argon2id
  
  1. set threads to 1..30, memory_cost to 65536, time_cost to 1 to find optimal number of threads, if more than one CPU core is available on the server
     
  2. set threads to 1 (or the number from the previous experiment that resulted in lowest time), memory_cost to 65536+131072..1048576, time_cost to 1 to check resulting time of memory costs from 64 MiB to 1 GiB, in intervals of 128 MiB
     
  3. with satisfactory number of threads, when memory cannot be increased further, set time_cost to 1..10 to check execution time for values from 1 to 10
     

After saving the choices in the ACP's Configuration → Settings → DVZ Hash and switching Update on the Fly to Yes, user passwords will be stored using the chosen algorithm not only during registration, password reset, and password change, but also on successful login. The statistics of this process can be observed in the ACP's Tools & Maintenance → DVZ Hash → Algorithms.



Securing Existing Hashes

Switching the algorithm on-the-fly during login will successively upgrade password hashes of individual users, but it will not affect users who are not active, or who won't need to login again any time soon.

While a direct conversion is not possible (it's technically infeasible to reverse a hash), the DVZ Hash plugin can apply the new algorithm over the old hash values. This operation is similar to moving an old, rusty safe into a brand-new one (we don't need to ask users to open the old safe to improve security).

In the ACP's Tools & Maintenance → DVZ Hash → Algorithms, use Password Algorithm Wrapping. By selecting mybb as Algorithm in Use and mybb_argon2id or mybb_bcrypt as Destination Algorithm, the system will apply the new method to passwords stored using MyBB's default algorithm — with specified number of hashes at a time (if the algorithm has been configured to take 0.1 s, one hundred wrap operations would take about 10 seconds).

After this operation, affected users will be able able to log in as usual, and their passwords will be checked by using the old algorithm first, and passing its result to the new algorithm: new algorithm ( old algorithm ( password ) ).

With the Update on the Fly option enabled, the password will be then saved using the new method only.







FAQ

• Does password hashing only address the problem of database intrusions and hacked forums?
  No. A MyBB database contains many values that rely on confidentiality, which includes password hashes. These can be stolen or leaked through vulnerabilities and bugs in MyBB, plugins, and other software installed on the server. Leaks are not limited to active installations, but also backups and staging/test installations, which may be accessed by someone else.
  
  
• Does the plugin affect forum functionality for regular users?
  No, DVZ Hash changes the internal operation of MyBB and should not be noticeable to forum users. Passwords resets are not required to switch and upgrade the underlying password hashing algorithms. Forum pages where users don't enter their account passwords will be unaffected by switching to a slower algorithm.
  
  
• Will password verification be slower on mobile devices?
  No — the password hashes are created on the server where MyBB is installed. The duration of this operation should be similar for everyone, and can be inspected in the ACP's Tools & Maintenance → DVZ Hash → Benchmark using parameters saved in settings.
  
  
• Do modern password algorithms provide absolute protection after a breach?
  No, forum administrators should still notify affected users and reset (or encourage them to reset) their passwords if they suspect such data may have been accessed by a third party.
  
  MyBB Documentation: Security Incident Response & Recovery →
  
  
• Should the parameters ever be changed?
  As new and faster hardware is manufactured and released, brute-force attacks on hashes of specific "strength" become easier and cheaper. This, however, also applies to server hardware, and thus whenever it's upgraded (or the forum is moved to a different server), the parameters should be corrected to require significant effort to derive a hash, on par with recent technology.
  Once the parameters are changed in plugin settings, outdated password hashes will be re-generated on login.
  
  
• Will the new hashes work after upgrading to MyBB 1.9?
  Users on forums with bcrypt and argon2id will be able to log in seamlessly on MyBB 1.9, which is expected to support modern algorithms by default.
  A 1.9-compatible edition of DVZ Hash will be required to continue supporting advanced features like hash encryption.
  
  

Also note that 1.9 will be using the new password_hash() PHP function to perform the hashing. This generates hashes that start with a small piece of data that provides information about the algorithm that was used and the settings (which can e read using the password_get_info() PHP function). This means that with MyBB 1.9, and onwards, if there are newer hash algorithms made available in the PHP core that are deemed more secure, we can easily upgrade to them without breaking old passwords and we can then upgrade old passwords as users log in using core PHP functions (such as password_needs_rehash()).

I think this is a good idea. But I also think just requiring complex 12 character passwords is a strong option for now. You can even do forced random passwords to prevent them from making bad decision of using same password across services. I think their PW should be set to them on signup instead of created too.

Also I have to ask, is this overkill for forum software? Seems like high-end password management worthy of bank logins. Does MyBB needs this? Is it a selling point to new admins? Does this change create more hassle for existing plugins and MyBB forum owners? And lastly, will this change require a lot of time to implement thus slowing down the release of 1.9x as resources of time seems rather limited.

Is this worth it?

I've also recommended in the past a $config['salt'] option in inc/config.php so that the password_hash() has another salt that's NOT in the database. Sometimes breaches are just the DB dump and not file access. A hard-coded salt in the config could give an admin enough time to do a full-site PW reset.

I've had my DB dumped btw. Was inconvenient surely but we're a forum and not a bank that holds funds. Ultimately it was more a problem that emails were dumped than PW's.

Strengthening the MyBB PW system is a good idea. I just feel it should be measured against resources and needs.

EDIT: Wanted to say great plugin btw. Most of my comments were because of the 1.9x mentions. I don't want to take away from the awesome work in this plugin at all.

Been using DVZ Hash plugin for a while, it has been great.
My question is related to upgrading from MyBB 1.8 to 1.9 in future.
Will DVZ Hash plugin affect the upgrade ?

Quote:Also I have to ask, is this overkill for forum software? Seems like high-end password management worthy of bank logins. Does MyBB needs this? Is it a selling point to new admins? Does this change create more hassle for existing plugins and MyBB forum owners? And lastly, will this change require a lot of time to implement thus slowing down the release of 1.9x as resources of time seems rather limited.

Is this worth it?

Yes, it's a baseline that applies to all sites and forums, regardless of purpose, similar to the adoption of HTTPS (which we underlined in 2016).

The plugin doesn't require the administrator's attention beyond initial setup. In the case of MyBB 1.9, the configuration described here is unlikely to appear in MyBB installation/upgrading steps - by using recommended algorithms and parameters out-of-the-box (that offer much better protection than MD5) we can improve the security of user accounts without getting the administrators involved in the technical details.

Generally, we want MyBB to be easier to use for webmasters with less experience, which includes making MyBB secure by default and letting it configure itself, rather than making security dependent on the administrators' will and ability to follow certain instructions manually (#1, #2, #3).
At the same time, we expect to remove friction for administrators who know what they're doing and would like want to customize the inner workings (so e.g. it would be possible to make the bcrypt cost higher using a configuration variable).

The scope of changes is limited to internal handling of passwords, and plugins that may interfere with how MyBB does it can take advantage of MyBB's password-related functions and plugin hooks.

The code for 1.9 is ready (see merged Pull Requests associated with https://github.com/mybb/mybb/issues/3530), and forum users and administrators who are not aware of the underlying algorithm changes & upgrades handled by MyBB are unlikely to notice anything.

Quote:I've also recommended in the past a $config['salt'] option in inc/config.php so that the password_hash() has another salt that's NOT in the database. Sometimes breaches are just the DB dump and not file access. A hard-coded salt in the config could give an admin enough time to do a full-site PW reset.

Encrypting the hashes is generally a better idea - the encryption key works as a pepper that can be changed/rotated (which cannot be done with appended strings that affect the hash value).

DVZ Hash can use keys from the config.php file or environment variables. This is a feature that would still be handled by the plugin in 1.9, but it may be implemented into core at some point.

(2020-01-17, 08:18 AM)WallBB Wrote: [ -> ]My question is related to upgrading from MyBB 1.8 to 1.9 in future.
Will DVZ Hash plugin affect the upgrade ?

It shouldn't cause problems. MyBB 1.9 will have similar code and database structure that's created by the plugin, and new passwords will use bcrypt by default.

Does it affect MyFacebook or other similar plugins with oAuth?

(2020-01-19, 08:19 AM)Eldenroot Wrote: [ -> ]Does it affect MyFacebook or other similar plugins with oAuth?

I wouldn't expect problems. External login plugins don't usually interfere with password values.

For plugin developers' reference, this file shows MyBB hooks used by DVZ Hash and how data is modified: https://github.com/dvz/mybb-dvzHash/blob...ontend.php

Quote:Encrypting the hashes is generally a better idea - the encryption key works as a pepper that can be changed/rotated (which cannot be done with salts).

I wasn't aware of the technical term "pepper" but it's exactly what I was suggesting.