Cache-directory and local security breach

Hi all,

winscp is a very comfortable way of securely transferring files. Many thanks to the people who wrote it and posted it on the web. Great Software.

There seems to be one minor issue creating a local security-breach: the files that are downloaded are cached in the users TEMP-Dir during transfer.
This is a serious problem when using WinSCP on public computers, internet-cafes, university etc.

Only after transfer the file is copied to the target-directory.
This means that it is very difficult to securely get rid of the file later.

Secure deletion of the target copy is easy but then the cached copy is still there. This may means that anyone using the PC after me will be able to read my files, unless I 1. remember to delete the cached copy AND 2. know that it exists AND 3. know where to find it.

This is a trivial but rather annoying issue that actually got me to use commandline sftp instead of the otherwise very helpful WinSPC.

Therefore I believe that WinSCP should _always_ use the target-directory for caching.

regards stn

winscp is a very comfortable way of securely transferring files. Many thanks to the people who wrote it and posted it on the web. Great Software.

You're welcome :oops:

Secure deletion of the target copy is easy but then the cached copy is still there. This may means that anyone using the PC after me will be able to read my files, unless I 1. remember to delete the cached copy AND 2. know that it exists AND 3. know where to find it.

• To avoid storing files to Temp folder, do not use drag&drop. Read FAQ about this topic (<invalid hyperlink removed by admin>).
  
• Files are not cached, they are just temporarily stored there, because of some technical reasons (when you use drag&drop source application=WinSCP does not know the destination, only target application=Explorer knows).
• After transfer finishes, they should be deleted. They are not for you?

This is a trivial but rather annoying issue that actually got me to use commandline sftp instead of the otherwise very helpful WinSPC.

There's no reason. Except for WinSCP does not support sftp yet. In fact it does already, but only I have such version now :wink:

Therefore I believe that WinSCP should _always_ use the target-directory for caching.

Sure, but I suppose, you don't think, I'm stupid enough to do it in this MORE difficult way, if I'd have another option. In fact, there's another option. But it won't work in all cases. Anyway I'm considering to implement it in next version (or the one after).

Hi, thank you for the explanation.

Yes, I get the point of the problem with drag and drop and WinSCP not knowing what directories are involved.

Since WinSCP ver. 2.2 it is possible to configure the temporary dir.
I just wonder: if the temp-dir can be set via the menu, then somehow WinSCP is able to process such a setting.
Then why not instead by default set it to the local dir from which WinSCP is started? Every EXE-file "knows" where it resides.

IMHO this (default-)behaviour of WinSCP would be logical as it straighforwardly without user-intervention avoids having anything lying around on the PC, except in a small controlled area (the local dir).

Also (if feasible) sounds to me like something very easy to do, as most of the work is done already.

WinSCP handles "external" security well. This means it effectively prevents anyone on the way from client to server from finding anything. This post is about "internal" aspects on the client-PC.

As you said the temporary files are correctly deleted as soon an WinSCP ist closed.
That exactly is the problem. I would like to explain this a little further, also explaining how potential problems arise on public PCs and on PCs in administered networks.

After the session the temporary file is deleted by WinSCP. It is no longer there. This means that I am actually prevented from using some "secure delete"-utility that overwrites data before it finally deletes the file. (I have a very neat small commandline-program for this)

This means that a simple undelete, easily done with many programs, will recover my data on the local harddisk.

Also, if WinSCP (or more likely windows) crashes, then WinSCP may not be able to delete the file. This means that the file is from then on permanently and forever on that harddisk, open to everyone.

This turns out to potentially be a problem on public computers (people using pc after me) and (more important) on any computer which is part of an administrated network with an excessively nosy administrator (e.g. at work).
It do get the impression that this kind of admin is quite common.

Imagine that you need your credit-card-number in some internet-cafe and after downloading it via scp/sftp from some well-protected server, you suddenly find it at least potentially in full public view.

One more: WinSCP has the huge advantage of running without prior installation (please keep it that way). That means that it can be easily and quickly transfered to any pc, even if only used once or rarely. This makes it an ideal tool for "on the road computing".

On those public pc's mentioned above it is usually not possible to install software and very certainly you cannot change system settings like the path to temporary directories. Therefore it is not easy to use the hints from the WinSCP-FAQ.


regards stn

guest wrote:

I just wonder: if the temp-dir can be set via the menu, then somehow WinSCP is able to process such a setting.
Then why not instead by default set it to the local dir from which WinSCP is started? Every EXE-file "knows" where it resides.

Temp file is used, because it is more probable that user have write-permissions there. More than that it is bad practise to write temporary data to 'program files' (I know that it's not your case).

As you said the temporary files are correctly deleted as soon an WinSCP ist closed.
That exactly is the problem. I would like to explain this a little further, also explaining how potential problems arise on public PCs and on PCs in administered networks.

...

To this I must repeat: do not use drag&drop. It solves everything. I hope that you already understand that I do not like all that stuff with temp dir as much as you do, but currently I have no other solution.

On those public pc's mentioned above it is usually not possible to install software and very certainly you cannot change system settings like the path to temporary directories. Therefore it is not easy to use the hints from the WinSCP-FAQ.

You can change it in preferences since version 2.2.

To avoid storing files to Temp folder, do not use drag&drop. Read FAQ about this topic (<invalid hyperlink removed by admin>).

I use WinSCP 3.1 and SFTP, and had some issues with resuming transfer.

1) I didn't realize that double-clicking is considered as drag-n-drop until I tried!
Suprise. :shock:

1b) Does resume work with this drag-n-drop? No?

2) Resume does not work if part of the file exists (e.g. after transferring part of it with e.g. other SCP program) but it is not named filename.filepart! Manual rename is an annoyance.

3) SFTP support is so welcome! Excellent per se! 8)

juhehe wrote:

1) I didn't realize that double-clicking is considered as drag-n-drop until I tried!
Suprise. :shock:

It is not. Double-click is used either to open file in associated application (WinSCP 3.0 and above only) or to download file to local folder (Norton Commander interface only and only if you check appropriate option in Preferences).

1b) Does resume work with this drag-n-drop? No?

Resuming does not work for drag-n-drop, unless you drop file to local panel of WinSCP (Norton Commander interface only).

2) Resume does not work if part of the file exists (e.g. after transferring part of it with e.g. other SCP program) but it is not named filename.filepart! Manual rename is an annoyance.

How do I know that existing file in local directory with same name is partial file or some older file version that was smaller?

martin wrote:

juhehe wrote:

2) Resume does not work if part of the file exists (e.g. after transferring part of it with e.g. other SCP program) but it is not named filename.filepart! Manual rename is an annoyance.

How do I know that existing file in local directory with same name is partial file or some older file version that was smaller?

Ask user for "Overwrite/Resume/Skip".

juhehe wrote:

Ask user for "Overwrite/Resume/Skip".

Another disturbing question, that would be useful only for minority of users. Sorry :-(

martin wrote:

juhehe wrote:

Ask user for "Overwrite/Resume/Skip".

Another disturbing question, that would be useful only for minority of users. Sorry :-(

OK. You are the boss. But with respect,
at the moment, WinSCP 3.1 asks for file overwrite confirmation,
and the choises are: Yes/No/Abort/Yes to all/No to all. If resume is permitted by the protocol, adding Resume to that list is not big problem to user, IMHO. If I remember correctly, if resume is permitted, there is another window asking for resume, and to get there, you have to press Yes on the Overwrite-confirmation-window.

ncftp is well-known and behaves this way: asking for resume/append/overwrite if the file alredy exists. wget's resume also assumes that if the existing file and the file to be transferred have same name, resume happens. But in those cases one cannot see from the file(name) if the transfer is complete or not, in WinSCP's case you can see that. But still the triggering of resume-action is different, which in itself is not a bad thing, but confusing for many.

--
juhehe