Expose credential-secret for encrypted credentials in adapter config

[mickym2]

With the last update - the encrypted credential are lost.
See change log for Adapter update 5.0.0

NodeJS 16.4.x is required Please check instance configuration and re-enter your passwords (encryption has changed).

Why is it not possible to expose an own encryption-secret key in the adapter config ? - When using an own encryption key this can be part of the backup as well. This is offered by settings.js - so it should no longer a problem to keep encrypted credentials - even after a fresh installation

/** By default, credentials are encrypted in storage using a generated key. To
 * specify your own secret, set the following property.
 * If you want to disable encryption of credentials, set this property to false.
 * Note: once you set this property, do not change it - doing so will prevent
 * node-red from being able to decrypt your existing credentials and they will be
 * lost.
 */
//credentialSecret: "a-secret-key",

[klein0r]

The secret is filled automatically

ioBroker.node-red/settings.js

Line 44 in bde78e2

credentialSecret: "%%credentialSecret%%",

Do you get the warning Unable to find system secret in system.config?

ioBroker.node-red/main.js

Lines 107 to 113 in bde78e2

	this.getForeignObject('system.config', (err, obj) => {
	if (obj?.native?.secret) {
	this.systemSecret = obj.native.secret;
	this.log.debug(`Found system secret: ${this.systemSecret.substring(-10)}**********`);
	} else {
	this.log.warn('Unable to find system secret in system.config');
	}

[klein0r]

Should have the same value as in previous version 4.0.3:

ioBroker.node-red/main.js

Lines 560 to 568 in b6d11f2

	adapter.getForeignObject('system.config', (err, obj) => {
	if (obj && obj.native && obj.native.secret) {
	//noinspection JSUnresolvedVariable
	secret = obj.native.secret;
	}
	// Create settings for node-red
	writeSettings();
	writeStateList(() => startNodeRed());
	});

[mickym2]

No - when i updated the test system - I got the message that my credentials can't be read - and I had to specify new ones. But if this is fixed for the future, then this can be closed. - I will not upgrade my production system as NodeRed 3.1.1 has some bugs in validation of standard nodes. (see node-red/node-red#4464)

OK I see the credentials are set somewhere else now.

   /** By default, credentials are encrypted in storage using a generated key. To
     * specify your own secret, set the following property.
     * If you want to disable encryption of credentials, set this property to false.
     * Note: once you set this property, do not change it - doing so will prevent
     * node-red from being able to decrypt your existing credentials and they will be
     * lost.
     */
    credentialSecret: "%%credentialSecret%%",

[mickym2]

So can be closed - as I assume that the internal credentialSecret is saved with the backups as well and future updates will not require reentering all credentials.

[klein0r]

With the last update - the encrypted credential are lost.

So that was never the case?

No - when i updated the test system - I got the message that my credentials can't be read - and I had to specify new ones.

???

[mickym2]

No - I had never problems with my flows_cred - but with the last update - it was clear for me that with a new credentialSecret that my flows_cred could not be read. May be I can show you the message which I got after the upgrade. ...

This is the message, which appears after the upgrade as new credentialSecret is specified in the settings.js:

So I closed this - as this message was clear for me - but before I had never problems with my flows_cred - I guess that a key was created by NodeRed as described and stored somewhere else.

[mickym2]

Should have the same value as in previous version 4.0.3:

ioBroker.node-red/main.js

Lines 560 to 568 in b6d11f2

	adapter.getForeignObject('system.config', (err, obj) => {
	if (obj && obj.native && obj.native.secret) {
	//noinspection JSUnresolvedVariable
	secret = obj.native.secret;
	}
	// Create settings for node-red
	writeSettings();
	writeStateList(() => startNodeRed());
	});

In my opinion with until adapter 4.0.3 (incl.) this credentialSecret was never set in the settings.js as per default in NodeRed. Therefore as described NodeRed created internally a key - but I dont know where this key is stored.

I can only see - IF the project function is enabled - the secrets are stored in the .config.project.json

{
    "projects": {
        "MWHome": {
            "credentialSecret": "41HGmm4jowbb6j???????"
        },
        "MWTest": {
            "credentialSecret": "41HGmm4jowbb6j???????"
        }
    },
    "activeProject": "MWHome"
}

[klein0r]

In my opinion with until adapter 4.0.3 (incl.) this credentialSecret was never set in the settings.js as per default in NodeRed.

Just check the code of tag 4.0.3:

ioBroker.node-red/main.js

Line 363 in b6d11f2

lines[i] = setOption(lines[i], 'credentialSecret', secret);

ioBroker.node-red/settings.js

Line 44 in b6d11f2

credentialSecret: "'%%credentialSecret%%'",

[mickym2]

Ok - but why does the upgrade not set an existing secret? - As you see from the screen shot - the existing flows_cred.json couldn't be decrypted.

[klein0r]

Thanks, after checking everything again, the replacement of the credentials string isn't working... I will create a PR

Wrong placeholder: credentialSecret: "%%credentialSecret%%",
Correct is: credentialSecret: "'%%credentialSecret%%'",

(strange concept, but okay)

[klein0r]

Please test 5.0.1

[mickym2]

Ok - many thanks - the credentials are accessible and no message appears after upgrade now. Great many thanks!!!

• As I said - I will wait until NodeRed problems are fixed.

[mickym2]

Supplement: The users with version 4.0.3 can upgrade without problems now, however users who want to upgrade from 5.0.0 to 5.0.1 will lose their credentials now. Only for your information.