Page 1 of 1

add support for backups via SFTP

Posted: Fri Feb 16, 2007 12:59 am
by lkremkow
abstract: Network based backup mechanisms suffer from a lack security or significant complexity in implementation. The additional support of SFTP, which could possibly simply extend existing features, would remedy this problem.

full rational: I need to manage backups for a fleet of nomad laptop users, or just a dispersed user base where the only point in common is an Internet connection. The idea is that various computer systems all call into the same server which manages the backups of the various users.

Naturally, this is theoretically already be possible using e-mail, FTP, VPN, or NetBIOS/CIFS/SMB backup.

E-mail is impractical, as large data volume (10GB +) can not be managed with this.

FTP/NetBIOS/CIFS/SMB is dangerous as both the server and the data transmission are very hard to secure. In my experience, securing such services is almost impossible. If we consider that a significant user base will be connecting at perfectly predictable intervals, this adds the sniffing attack vector as it makes it much easier to target the transmission of data.

VPN as a security wrapper is also impractical as it dramatically slows down performance one the one hand (4 hours for just 500 MB in my trials) and adds a layer of complexity that makes it impossible to render the backup service transparent to the user.

The solution I envisage, and hereby request, is the additional support in AISBackup for SFTP, i.e. FTP implemented through SSH. This does not refer to tunneling FTP connections through a SSH connections (which is impossible) nor the use of SSL around classic FTP, but the SSH protocol implementation of FTP.

This adds two things: encrypted transport of data such that data that is being backed-up can not be sniffed and neither can credentials on the remote backup server, and additionally an FTP implementation that does not require an control channel and a data channel. SFTP through SSH would even support the use of pre-shared key files, which significantly simplifies the secure management of numerous systems for automated use of credentials.

The complexity of this task should be fairly low, as the basic transport model is that of FTP, which is already supported, and libraries that can be called upon to simply add a wrapper exist abound (OpenSSH, PuTTY, etc.).

Thanks for your consideration.

Secure FTP

Posted: Fri Feb 16, 2007 9:49 am
by Barry
The development version of AISBackup has implemented Explicit and Implicit SSL FTP. As you mentioned the initial handshake is not encrypted until the remote system receives the command to start an encrypted session, however, sniffer tests have shown that the remainder of the transfer session is encrypted.

The SSL encryption is on top of the normal zip file encryption, so essentially the actual backup data is encrypted twice.

SSH SFTP will be investigated but this is unlikely to be in the next release, and we must also be careful that we do not break any international laws on the export of cryptography software. http://en.wikipedia.org/wiki/Export_of_cryptography

Barry

FTPS versus SFTP

Posted: Fri Feb 16, 2007 11:21 am
by lkremkow
Hello Barry, thanks for the prompt response.

I am glad to hear that FTP/SSL is on the road-map. I trust that it will be possible in AISBackup to:

- require FTP over SSL (or fail so as not to send in clear text)

- require a certain server certificate (or fail so as to make sure we are talking only the right server)

- and to define custom client side certificates (or fail, to provide identification to the server)

Whilst I do still prefer an SSH implementation, but if FTP/SSL is added this would address the technical requirements, just not the personal preference.

I am fully aware that wanting to doubly encrypt (from within AISBackup and over the SSL channel) may seem wasted CPU time. However, I do not use AISBackup encryption, thus the SSL channel would be my only encryption.

This brings up a point (off topic) regarding AISBackup encryption. I have not yet found (nor vigorously looked) for a detailed analysis of your password protection implementation. I know that the classic ZIP file passwords are not worth the effort. Your additional password promises to resolve this, but I do not understand how this is done, so I am not relying on it.

Lastly, one of reasons I very much appreciate AISBackup is that it uses a commonly interpreted file format (the afore mentioned ZIP), such that I am not forced to have AISBackup at hand. I can open the archives on any platform capable of opening ZIP files. Using your "closed" additional password breaks this functionality that I appreciate.

Could you possibly comment on the time frame for release of the new version with FTP/SSL functionality?

SSL

Posted: Fri Feb 16, 2007 11:58 am
by Barry
'SSL Required' will be added to AISBackup.

Certificate checking has not been looked at – but it will now you mention it.

AISBackup's password just generates a 40 character password from a user supplied password to avoid dictionary attacks. I have never come across a 'non-brute force' or ‘dictionary attack’ zip file password cracker even when using standard zip file passwords, is there one? As understand it, 40 characters will take several years to crack. If there is such a thing then we will redesign the backup file and use stronger encryption. Standard zip file encryption is very fast compared to AES etc.

Our zip file become non-standard if NTFS security settings are backed up, or rather the zip file is standard, the file data portion contains extra meta data. (The BackupRead and BackupWrite API is used when NTFS security settings are selected)

Would you like to try what we have got so far?

Barry

ZIP encryption

Posted: Sat Feb 17, 2007 12:56 am
by lkremkow
When you say “40 characters”, you do mean a 320 bit key? If that is so, then that does significantly increase the brute forcing time.

Where I am a little confused is that you refer to standard and AES encryption. WinZIP as of version 9 is based on AES. This suggests that your encryption is based on pre-AES techniques as you say you currently don’t use it.

This all aside – there is a major flaw in ZIP encryption: the meta-data is not encrypted. It is therefore possible to extract valid file names, original files lengths, etc. from the encrypted ZIP file (http://www.cse.ucsd.edu/users/tkohno/pa ... winzip.pdf).

Lastly, in terms of brute forcing time consider AccessData’s products, specifically the “Password Recovery Toolkit” or even the “Distributed Network Attack” (http://www.accessdata.com/).

Thank you very much for you offer to test, but I’m afraid I would not have the time needed to give the attention the testing deserves.