2

Suppose a client C wants to transfer form a service provider P, who collected data on behave of C using a web-application. Additionally, suppose the amount of data is larger than 100 MByte and contains privacy related information. Thus, the data needs to be protected against third party access.

C and P operate within their own local network, both have access to the internet. The workstations and servers in C's and P's local network are assumed to be secure.

I'd like to know, which of these transfer methods is preferable and why:

Option A: Use SFTP to transfer files.

Option B: Use a simple web-application to download data directly from the web-server. Use HTTPS to protect the transport layer and a userID with a long/random password to gain privileged access. In this case, web-app would be able to dynamically export data and advertise it as a file to the browser.

Option C: Partition data into sufficiently small packets, encrypt each part with GnuPG and forward it using e-mail.

From a security point of view, are all options probably equivalent?

Or is the fact, that Option A and Option C require the creation of temporary files, less secure than just in time generation of the export file using Option B?

Improve this question

3 Answers 3

Reset to default
2

From a security point of view, your options are NOT equivalent. Whether this is important or not depends on the context.

The first two methods are, roughly, equivalent in security: in both case you're using encryption of data in transit and rely on the complexity of you access password to protect the data. The security challenge you're going to get here are pretty much in the line of: protecting against MitM attacks and password cracking. In both case, you'll have to setup this carefully and properly to prevent MitM and in both case you'll require a separate secure channel for exchanging keys (in your case, the password).

You could make it stronger by using public/private key pairs for authentication though. Another issue is that, since the data is not encrypted on the server (at rest), any flaw in the server software or setup might grant access to your data to an attacker.

The third method is different. Although you will still require a separate secure channel to exchange passwords, you are not relying on encryption connection for confidentiality. This means that the whole setup is more resilient since breaking one layer of protection (say, your mail server) will not grant an attacker access to the data.

That being said, you could improve on that design a lot. For instance, using a SFTP server to host an encrypted PGP file will make everything both more secure and more practical. If you're willing to trust your keys to some machine in your internal network, the whole thing can be automated.

As for temporary files, only if they really mater in your use case, then your requirement is strict enough that you should NOT try to implement that yourself but hire a professional. In general, temp files are as secure as the other files on your machine: if your machine is secure enough, so are your files. And if you have a temporary, non-encrypted files uploaded to a server somewhere, that file will be as safe as the "real" copy that you intend to leave there (i.e. not very much).

Improve this answer
1
  • I would take as requirements from your explanation: - protect data at rest - protect data during transfer - protect keys - resilience, i.e. how does breaching one level of security impact the other levels and the overall security of the system What about data during processing? E.g. while the server encrypts data or sends data it is stored in memory and might be decrypted from the at-rest protection as well, while not being inside of the at-transfer protection. And should I distinguish different parts of the data based on usage and security needs? Commented Oct 12, 2022 at 13:44
1

As you would already know that there is no such thing as absolute security but my approach would be like this:

  1. Encrypt the data using a strong password (Truecrypt AES-256 et. al.)
  2. SCP of SFTP the data to the new location.
  3. Decrypt and verify the data at the new location.
  4. Secure delete the data at the old location.

The creation of temporary files doesn't reduce security but option B has an additional attack vector in the web-application itself and I'd go for OpenSSH over any other web application any day.

Improve this answer
1

Option A: C needs to be able to access SSH on Ps network (static ip on both sides should be given to create necessary firewall-rules), and C should use SSH-Keys, then this would be an option. P can restrict/chroot Cs accesses to sftp and a certain directory.

Option B: Basic/Digest-Auth + SSL to access this file should be fine, but login/password-transfer shouldnt be done via internet. additionally P you issue an password-protected client-cert to C for authentication. if C is behind a static ip, use a firewall to protect that service.

Option C: only if A/B is not an option. in this case you could also encrypt and upload to rapidshare et al :)

anyway, the file should be deleted after successfull transfer.

which of these transfer methods is preferable and why:

that one that is easier to setup and maintain.

secure transfer should be given in all 3 cases, but if P has implemented VPN-restricted SSH-access and dont want to give C VPN-access then HTTPS might be a better solution.

if you care about creation of temporary files or in-memory-attacks you can ask P to setup a dedicated server for your file-transfer.

Or, like Fahad Yussuf suggested, encrypt that data before placing it onto an internet-facing server; this would prevent any issue with temporary files and is a good solution. encryption can be scripted, but decryption would need an human involved, except when you run some kind of daemon on the receiver that works with gpg/gpg-agent, but this would be a little overdressed?

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.