@Hackwar can you have a lock at this please? Is it needed to save the e-mail server settings in the db?!

This is fairly trivial to address and I have implemented it in a generic way in FOF3. It's no longer just Akeeba Backup. The idea is that the encryption key is stored in the filesystem while the encrypted data is stored in the database. Just a SQL injection won't be enough to divulge the secrets. If someone has full read control over the filesystem it's game over anyway; they have database access and filesystem access, your site is compromised. This is the same idea we used back in late 2012 with the two factor authentication data being encrypted in the database.

If you have or are about to implement the split secrets Tobias and David were talking about several months ago you can of course use the secret meant for encryption to encrypt this information in the database. If you have not implemented this yet you can use the current secret since the way it will be implemented — at least according to the discussion we had last summer — is that the current secret will be used for encryption and a new one will be used for hashing session data and other publicly visible information.

I would have normally offered to help but I've been dissuaded from contributing so many times it's no longer funny. I'd like to preserve my sanity and my time. I've told you how to do it, any developer worth being a core contributor can implement it.

I am unsubscribing from this thread since it's not productive for me to participate in a discussion when I know that I won't be allowed to contribute code for it anyway. Not to mention that Hannes definitely doesn't like working with me, especially when I am right.

Thank you for unsubscribing.

Would be cool if we use 1 global email config.
Spreading them around can make the site migration much harder, also this make harder to use Dev/Live installation for people who have separate environments for Dev/Live

Looking at the code the email settings are alternative settings for single mails I would suspect it's part of the 'alternative_mailconfig' and is unset if not used.

This feature is not really useful for core but for 3rd party extensions. Encrypting the sensitive data would make sense and should be done. On the other side if a hacker can make a sql injection he/she has already won the war.

This issue was reported to the @joomla/security JSST team on 8th January 2021...

To date, I have not received a reply. It's now May.

and now its almost march 2022

Are you surprised? I still have serious security issues open with the JSST for YEARS!