#594 PR merged: Backup log contains the BACKUP_PROG_CRYPT_KEY #568

davixd opened issue at 2015-06-07 11:12:

Rear topic:
Backup log contains the BACKUP_PROG_CRYPT_KEY

Issue:
#568

davixd commented at 2015-06-12 21:57:

Iam using the following settings in /etc/rear/local.conf:
BACKUP_URL="nfs://10.0.xx.xx/backup/"
BACKUP_PROG_CRYPT_ENABLED=1
BACKUP_PROG_CRYPT_KEY=”testpw123”

On the nfs target server:
[root@fs-01 rear-backup]# cat backup_rear-backup.xxx.int_2015-03-26T14:50:16+0100_crypt_des3.log
2015-03-26 14:50:37 tar --warning=no-xdev --sparse --block-number --totals --verbose --no-wildcards-match-slash --one-file-system --ignore-failed-read --anchored --gzip -X /tmp/rear.b7bE08LIU8DwWBV/tmp/backup-exclude.txt -C / -c -f - / /var /boot /var/log/rear/rear-rear-backup.log | /usr/bin/openssl des3 -salt -k ”testpw123” | dd of=/tmp/rear.b7bE08LIU8DwWBV/outputfs/rear-backup/backup_rear-backup.xxx.int_2015-03-26T14:50:16+0100_crypt_des3.tar.gz
tar: Removing leading `/' from member names

on the rescue medium:
BACKUP_PROG_CRYPT_KEY=”testpw123”

Because nfs use no encryption, it is not a good idea to send the password of the crypt backup true the same line. Its also not a good idea, to leave the password in clear text on the nfs target server.

With this change file the password is blanked in the logs and rescue medium.

A possible scenario (even when the nfs-server is only accessible by the clients which will be backuped):
client1-to-backup-> nfs-target-server
client2-to-backup -> nfs-target-server

The userA has the permissions to mount nfs-target-server on client2. In this case userA can read all files on client1, because the user can decrypt the backup file of client1 (password is accessible in clear text in the log file or rescue medium).

Or the backup line is intercepted by an intruder. The same result here (password is accessible in clear text in the log file or rescue medium, so the intruder can decrypt the backup file).

Or to you have a best practice for me in this use case?

davixd commented at 2015-06-25 16:37:

@gdha, yes it was on purpose. With this setting everything is working fine, the backup and recover still works. You have to do the change, to leave the password blanked in the rescue-iso (/etc/rear/local.conf). I have done this change already months ago, but I will test it again. You can try it yourself (make the change). My /etc/rear/local.conf you have in the posts above.

But like I already told in Issue #568, for me it works fine, but I dont know what site effects it can have, I didnt found any till yet.

[Export of Github issue for rear/rear.]