I was testing the new S3 backup option and while the functionality was flawless I'm concerned with my secret key being saved as plain text in the database. It is critical that I keep this key private, which means that I can't allow users to download their backups if I use S3 as the storage option.
As a potential workaround I tried excluding the table with the data but this doesn't work either as users can choose which tables to download if they are allowed to download their backups. As well, not including this table would mean that restoring from a backup would erase the previous settings.
I could see two options for fixing this:
- Allow the S3 connection information to be stored in code in the same way settings.php contains the database information.
- Use encryption on the password field.
Alternately, I could understand if this is marked as "won't fix" as there is a clear warning that sensitive information could be exposed by using this module.
Comments
Comment #1
ronan commentedI'm not sure password encryption would help (you'd need to store the key to decrypt the password which sort of defeats the purpose). Storing the key on disk may help mitigate the security issues, which dovetails nicely with #373786: Add option to store backup profiles in code.
I feel like that should be the way to go here, but I'm not going to make it a very high priority since, as you say, there's something inherently dangerous about db backups in the first place.
Ronan
Comment #2
rickvug commentedI agree that storing configuration on disk is the key. It would solve this issue and open open up additional options.
Comment #3
ronan commentedI'm going to mark this as fixed since #373786: Add option to store backup profiles in code now allows storing secret keys on disk.
Thanks
r
Comment #5
elijah lynnWhere is the Amazon S3 option?
Edit - Nevermind, I see you are using the latest dev version (noob here).