View Issue Details

IDProjectCategoryView StatusLast Update
0017849mantisbtupgradepublic2016-08-08 16:00
Reportervboctor Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status confirmedResolutionopen 
Product Version1.3.0-beta.1 
Summary0017849: Salt missing error not very helpful for users

I've created a new folder with a different URL mapping, pointed it to a copy of the official bug tracker database and navigated to the URL and got the following error. This error doesn't help the user to know how to fix the issue. Should we redirect to the installation pages?

For security reasons MantisBT will not operate when $g_crypto_master_salt is not specified correctly in config_inc.php or is shorter than 16 characters long.
Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

TagsNo tags attached.


related to 0014087 closedvboctor Installation script doesn't set the crypto_master_salt causing errors 
related to 0010730 closeddhx Improve random number generation with openssl_random_pseudo_bytes 
has duplicate 0021409 closeddregad APPLICATION ERROR #2900 during update 
has duplicate 0021666 closedatrol Upgrading from 1.2.19 to 1.3.1 




2014-11-08 17:04

manager   ~0041798

Even after successfully upgrading the database and clicking the link to go the instance, the same error surfaced since the salt is missing due to upgrade not writing the config_inc.php.



2014-11-09 04:10

manager   ~0041814

I've looked at the code to figure out where the salt is used. It is used for the following tasks:

  • generate random passwords
  • generate login cookies
  • form security tokens.
  • used in signup_page.php to generate a variable, that doesn’t seem to be ever used. signup_page.php - $t_public_key = crypto_generate_uri_safe_nonce( 64 );
  • used in file api to generate unique name.

Changing this value doesn't cause issues. Hence, my question is why don't we use the combination of the following fields as the salt and get rid of this variable?

  • database name
  • database user
  • database password
  • config timestamp (optional)




2014-11-09 04:10

manager   ~0041815

Reminder sent to: atrol, dregad

Would like your input on dropping the salt config option in favor of an auto-calculated field.



2014-11-09 04:51

developer   ~0041816

I'm by no means a security or cryptography expert, but from my limited knowledge salts should be random and unpredictable. Using a calculated field defeats this purpose, and from that perspective having this master salt variable makes sense.

You might also want want to read dhx's prose in commit message for fix to 0010730 for some justification of this error.

Anyway, considering that this message should in theory pop up just once after an upgrade and would therefore be only be shown to the administrator, I would suggest not to sacrifice security on the altar of usability.

Though we can probably make things easier, either by providing a recommended addition to config_inc.php in the output of installer (in upgrade mode) and maybe improve the message in admin checks.



2014-11-09 12:20

manager   ~0041819

There is two pieces of work involved here:

  1. Use a better random hash generator.
  2. Use a salt.

I just don't know how the process id (by php), timestamp (by php), database name, database user, database password, config_inc timestamp are predictable to someone who can see a set of hashes.

My question is whether we should keep 1 and calculate 2. I read dhx's comment, but it doesn't answer my core question. I'm still convinced that we are just complicating things will no extra value.



2014-11-10 03:08

developer   ~0041822

I'm by no means a security or cryptography expert
Same for me, thus don't ask me if this stuff is some kind of paranoia of security guys or a real scenario.

The more you know something about the salt the less effort you need for brute force attacks.

E.g. you could guess that the database name is "mantisbt", ...



2016-08-08 16:00

reporter   ~0053761

$g_db_type = "mysqli";

I use an old configinc and the cause was $g_db_type = "mysql";

Issue History

Date Modified Username Field Change
2014-11-08 16:59 vboctor New Issue
2014-11-08 16:59 vboctor Status new => assigned
2014-11-08 16:59 vboctor Assigned To => dregad
2014-11-08 17:04 vboctor Note Added: 0041798
2014-11-09 04:10 vboctor Note Added: 0041814
2014-11-09 04:10 vboctor Assigned To dregad =>
2014-11-09 04:10 vboctor Status assigned => confirmed
2014-11-09 04:10 vboctor Note Added: 0041815
2014-11-09 04:11 vboctor Target Version => 1.3.0-beta.1
2014-11-09 04:40 dregad Relationship added related to 0014087
2014-11-09 04:42 dregad Relationship added related to 0010730
2014-11-09 04:51 dregad Note Added: 0041816
2014-11-09 12:20 vboctor Note Added: 0041819
2014-11-10 03:08 atrol Note Added: 0041822
2014-12-08 02:10 atrol Target Version 1.3.0-beta.1 => 1.3.0-beta.2
2014-12-13 17:18 vboctor Product Version 1.3.0dev => 1.3.0-beta.1
2015-03-15 19:59 dregad Target Version 1.3.0-beta.2 => 1.3.0-beta.3
2015-09-06 17:47 vboctoradmin Target Version 1.3.0-beta.3 => 1.3.0-rc.1
2015-12-06 02:55 vboctor Target Version 1.3.0-rc.1 => 1.3.0-rc.2
2016-06-12 02:37 atrol Target Version 1.3.0-rc.2 => 1.3.0
2016-07-10 07:57 atroladmin Target Version 1.3.0 => 1.3.1
2016-07-11 16:10 atrol Target Version 1.3.1 =>
2016-08-08 16:00 mahindra Note Added: 0053761
2016-08-09 11:55 dregad Relationship added has duplicate 0021409
2016-09-06 17:12 atrol Relationship added has duplicate 0021666