View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0017849 | mantisbt | upgrade | public | 2014-11-08 16:59 | 2016-08-08 16:00 |
Reporter | vboctor | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | confirmed | Resolution | open | ||
Product Version | 1.3.0-beta.1 | ||||
Summary | 0017849: 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 | ||||
Tags | No tags attached. | ||||
related to | 0014087 | closed | vboctor | Installation script doesn't set the crypto_master_salt causing errors |
related to | 0010730 | closed | dhx | Improve random number generation with openssl_random_pseudo_bytes |
has duplicate | 0021409 | closed | dregad | APPLICATION ERROR #2900 during update |
has duplicate | 0021666 | closed | atrol | Upgrading from 1.2.19 to 1.3.1 |
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. |
|
I've looked at the code to figure out where the salt is used. It is used for the following tasks:
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?
Thoughts? |
|
Reminder sent to: atrol, dregad Would like your input on dropping the salt config option in favor of an auto-calculated field. |
|
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. |
|
There is two pieces of work involved here:
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. |
|
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", ... |
|
$g_db_type = "mysqli"; I use an old configinc and the cause was $g_db_type = "mysql"; |
|