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
Description

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?

APPLICATION ERROR #2900
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.

Relationships

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 

Activities

vboctor

vboctor

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.

vboctor

vboctor

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)

Thoughts?

vboctor

vboctor

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.

dregad

dregad

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.

vboctor

vboctor

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.

atrol

atrol

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

mahindra

mahindra

2016-08-08 16:00

reporter   ~0053761

$g_db_type = "mysqli";

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