Safe launching and possible security risks and data loss

There are few security risks when using jdbdump. The following list describes them and suggests a solution:

• Not encrypted username and password when logging into the system.
  We strongly suggest using an SSL enabled web server in order not to be sniffed by third party's spy software.

• Other users of the system that jdbdump is being launched on may read jdbdump files.
  In this situation we strongly advise to check whether the files created by jdbdump (e.g. backups) are readable only by ,,tomcat'' user (in case you are using Apache Tomcat server).

• Not encrypted database image files transferred from the server to the user's computer.
  This might be harder to sniff, because transfered images are stored in a serialized and zipped / gzipped format, but there is still a possibility that someone nasty will log the whole image and then try to find some passwords. That is why we also recommend to download the image file via an SSL channel, which is however pretty slow. In the future versions secure ftp transfers should be implemented. The other solution is to encrypt the image file using e.g. a password algorithm and then use that password to retrieve image.

• Database images are stored temporarily in the server's working directory.
  In case the server is tomcat, on every reload or deployment of the project probably all backed up data is lost. It means that users need to download the image file before someone does one of the mentioned things. This is normally not a problem, however we suggest to download the image file just after it is being done.
  The best solution would be to create another implementation of DumpFileManager, which would upload files to a remote database as blob objects instead of saving them in the filesystem. Then they would be protected from malicious sysadmins.