Command line password file

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!

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

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.

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

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 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 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?

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

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?

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

Thank you!

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

@itmanag: What is your use case?

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

@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.

Thanks!

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

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.

@p-st: No I mean implicitly used variable, like
The way for example sshpass uses SSHPASS variable.

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: 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.

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".

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

Ok, sounds great!

@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.