@p-st: I'm sending you an email with a development version of WinSCP to the address you have used to register on this forum.

Ok, sounds great!

Thanks for your feedback. I'll contact you, once I have anything to test.

Of course the environment variable would be already more secure than the status quo, so I think it makes sense to implement it. And even better, if point 2 isn't an issue. I think we would need 4 environment variables to be able to get rid of all possible passwords in the command line parameters (at least for the protocols sftp/scp):

What do you think?

EDIT: I think WinSCP should delete the value for the environment variables after reading them. Otherwise, the passwords would be readable with tools like "Process Explorer".

@p-st: I understand that it's not as good solution. But it's also easier to implement. Also note that each process has its own environment, so your second point is not valid.

I see. In the man page of sshpass they write:

In particular, people writing programs that are meant to communicate the password programatically are encouraged to use an anonymous pipe and pass the pipe's reading end to sshpass using the -d option.

I agree with this. When a environment variable is used, the password is not written to the file system, but you still have problems:

• When shall the environment variable be deleted? It is more complicated to check if WinSCP has read the variable than with pipes
  
• Also, what happens if multiple instances of WinSCP get started concurrently? If there is only one environment variable WINSCP_PASSWORD this would be a problem because of race conditions
  

@p-st: No I mean implicitly used variable, like

The way for example sshpass uses SSHPASS variable.

Do you mean like this?

Afaik the password will still be visible in the command line parameters of the process, as the environment variable will be replaced before the execution.

Btw, wouldn't an environment variable be an option?

Thanks!

@p-st: Makes sense. I have added this request to the tracker:
Issue 2102 – Reading password from a file and
Issue 2118 – Reading password from a named pipe
You can vote for it there.

Hi Martin,

thanks for your great work! I'm the author of WinSSHTerm, which makes heavy use of WinSCP's and PuTTY's command line parameters. I just successfully changed the implementation from using -pw to -pwfile for opening PuTTY sessions.

Please let me explain how I did this. It will show my use case. Instead of creating a usual file in the file system, writing the password into it, passing its path to the -pwfile parameter and finally deleting it somehow, I took advantage of Windows' named pipes (motivated by this question on StackOverflow Securely pass password to PuTTY process on start). Pipes can be accessed like a file, but in a more secure way:

Named pipes are similar to files, but they are stored in shared memory:

• At latest after the system reboots, named pipes are definitively deleted. Files on the file system however persist. So in case the password file would not get deleted accidently we would have a file containing a password inside lying around on the filesystem
  
• Even if we delete the password file on the file system, it is possible to recover the file as its content won't be deleted at once (this is how NTFS works)
  

Named pipes support a server/client concept. This is how WinSSHTerm uses it when opening a PuTTY session, that uses a password as authentication:

1. A named pipe is created with a random name, let's reference to it with mypipe for simplicity. The file is now accessible by the URL \\.\pipe\mypipe
   
2. Now WinSSHTerm (the server for the named pipe) waits for a client to connect, that is – PuTTY accesses the pipe for reading
   
3. PuTTY gets launched with -pwfile \\.\pipe\mypipe and accesses the pipe to read the password
   
4. WinSSHTerm will detect the client connection, and will now write the password into the pipe and then disconnect from it – note that until the client connects, the pipe is empty
   
5. PuTTY will read the password from the pipe and complete the read operation by disconnecting from it
   
6. Now there is no process connected to the pipe any more, which means the pipe gets automatically deleted
   

So my use case for the command line parameter -pwfile would be a secure way to communicate the password to WinSCP (more secure than e.g. using WinSCP.ini). It would be great if WinSCP would also support that.

Regards,
Patrick

@itmanag: What is your use case?

+1 for this.
I'm stated to use this sharing protocol with PuTTY 0.77 and it's awesome!

Thank you!

OK, I'll see if more people have this quite specific requirement.

Yes, because all systems running with read only file systems have a scratch memory filesystem (TEMP). So the INI file of the WinSCP is not editable, but you can share the TMP directory.

Please, why not implement this simple solution that is already included in PuTTY?

And the password file is an option with read only file systems?

Hi Martin,

I think the password in a file is more simple than other options. Why? First, in a Portable environment the Windows registry has no sense. Also the INI file is not an option with readonly filesystems. Why are you so reluctant to this simple and already standardized mode?

So if you can setup some process that can write the password to a file, cannot you instead write the password to WinSCP INI file or Windows registry and have WinSCP use that?

I know that the latest version of PuTTY has that option. But WinSCP has other options for providing the password for years that PuTTY does not have (like script file, INI file or registry).

Hi,

I'm not storing anything in any part!
What I want is to launch WinSCP without incorporating the PASSWORD in the command line (a very unsecure behaviour!).

So now I can do: winscp.exe user@server /password=MY_PASS

And what I want to do is: winscp.exe user@server /pwfile=C:\TMP\hash.data

Where the file C:\TMP\hash.data is a temporal file created by someone that includes the password in a clean form. For security this file will be created with a very restrictive ACL and automatically removed after WinSCP will starts (that's after reading it, so it will be perfect if optionally WinSCP will delete such file after read it).

And please don't think this is something new. In fact, the PuTTY team has already implemented it in the mainstream of his tool. So, I suggest that you now implement the same for WinSCP.

Thank you.

So it's about starting WinSCP GUI?
How would you store the password to the file from KiTTY?

Use case:
From external TERM session (for example, using KiTTY) you want to open the WinSCP from the command line.
Now this is done using the plain password in the command line (very easy to read it). Using this technique it's more safe to launch the WinSCP session.

What is your use case? When you need to specify the password on WinSCP commandline?

Hi,

In the current documentation of the command line parameters
(https://winscp.net/eng/docs/commandline) I see only the option to share the password using the argument /password=<pass>. However, this has a high risk, as with the Windows Task Manager you can see the command used to launch any process.

The last version of PuTTY has incorporated the option to share the password over a file.
See here the description:
https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/cmdline-password-file.html

My request is to implement just the same. You can do it please?
Thank you!