Daily change of Akeeba Secret Keys (?)

[Rolli1962]

Had running an own script, which do a daily backup of my sites via remote backup.
Since activation of Panopticon it wasn't running any more. The Secret Keys where changed. Change those in my script, tested it successfully. Next night backup failed again. Secret Keys where changed.

Seems Panopticon change those on a daily base (I'm a little bit unsure)?
Today I have activated the scheduled backup in Panopticon, deactivated my script.

Would be nice to hear an agree that the keys are changed on regular base and maybe those written words are helpful for other admins ;-)

Best - Roland

[nikosdion]

The connector will regenerate a Secret Word for the Akeeba Backup JSON API if your existing Secret Word is empty, cannot be decrypted, or too weak (in which case the JSON API would not allow you to connect).

The latter is important. It's an Akeeba Backup feature that's been around for several years already. Since the JSON API lets you do a lot with Akeeba Backup that could potentially be catastrophic to your backups and your ability to take backups, the JSON API will refuse to operate unless the Secret Word meets a certain level of complexity. This automatically determined by a third party library called Complexify. The connector needs to make sure that Panopticon can connect to Akeeba Backup's JSON API. The way for this to be ensured is to ask Akeeba Backup of the Secret Word meets the minimum level of complexity and, if not, regenerate it in a way that it will pass the complexity test.

Is it possible that every day you are changing your Secret Word back to something you were using before, and every day Panopticon's connector sees that it's too weak for the JSON API to use and resets it?

Have you tried using the Secret Word created by the connector in your scripts instead of changing back your secret word to what it was before?

[Rolli1962]

I am a little bit confused - not about your words.
After the first automatic change I let the new secret words, changed them in my script and tested it.
Next day the secret words changed again every day. Except today. But this was also the first night, where I tried to let panopticon make the backups. My script deactivated.
After reading your statement I matched two secret words of two day together, very long. Set it on the sites manually, also in my script. Tested backup via this script and very long secret words - was running.
Back to Panopticon - there was the statement connection lost to Akeeba backup. Had re-synchronize the connection, panopticon set a new secret word. Hopefully those will stay.
Think more for another tread - have two sites with lot of pics, backup has over 2GB. Those backups are not working via panopticon. Seems they are hanging during the process.

[nikosdion]

I tried reproducing your issue with this configuration, but PHP 8.2.12 (8.2.2 is ancient and has no business being on a live server, albeit it won't have any effect on this issue). I could not reproduce it.

Go to Akeeba Backup, Options, Back-end and set Use Encryption to No, then Save & Close. Did that help with your problem? I have a feeling that every now and then your server fails to decode encrypted settings causing the problem. Disabling encryption should solve that problem. Let's see if my guess is right.

[Rolli1962]

Yes, can confirm. To be sure I made a little change for the site, view the backup, did a backup per my script, again did a change for the site, view the backup - secret word stayed. Super!

[nikosdion]

OK, that's weird. There is definitely something going on with the encryption key file on your server. I just don't know what exactly just yet.

[Rolli1962]

Think it would be difficult with the provider to fix it. Could I let the switch to off?
And - thanks for the support!

[nikosdion]

Yes, you can definitely leave this off. It's a paranoid-level feature, not something you absolutely need (otherwise it wouldn't be an option to begin with). The idea here is that if your site is hacked with a vulnerability that only allows dumping the contents of the database you'd still be pretty safe since the backup configuration would be encrypted in the database, needing a key stored in the filesystem to be decrypted. Of course, if said vulnerability is a true SQL injection then the attacker can also take over the site completely, in which case nothing saves you.

As you understand, the reason I developed this feature is that people who only partially understand security were grumbling discontentedly at me even though I had told them that the change of an SQLi vulnerability which would allow an attacker to only dump data is far less likely than a full SQLi which would defeat this mitigation. These people insisted, so there is the feature that's not really needed but causes a lot of trouble. If I were in this situation now, with another 10 years of experience on my back, I would have made this an opt-in feature instead of an opt-out feature, with a big red warning that it may cause things to break randomly for reasons outside my control. Live and learn…

[Rolli1962]

Thanks! Working well with setting Akeeba Option Back-end -> Use encryption to NO. Think discussion can be closed. (hope now it will be closed)