Anonymous wrote:

B) The script engine should convert the URL-encoded password back before sending it to a sever.

Of course it does.

If you go for option B, I suggest adding a security improvement: if the scripting engine has to decode the password anyway, why not make it a bit more secure by really encrypting the passwords in the generated URLs?

That's not encryption. That's mere obfuscation.
See https://winscp.net/eng/docs/guide_protecting_credentials_for_automation

I won't be following this up any more since my workaround is working fine.

Would you please attach the log anyway? It might be useful. You can even enable password logging in preferences (or use /loglevel=* command-line parameter).

You state that

Note that passwords and passphrases not stored in the log.

Therefore a log would not be useful at all.

That log would just say that the wrong password was used, which is perfectly correct.

The reason the wrong password is used is what counts: the "Generate Session URL" feature changes the password from the entered/stored one, when that password includes a comma.


Test case:
1) Set up an account with a password that begins with a comma
2) Make a new entry for that account in WinSCP, and store the password.
3) Connect to that account using the WinSCP GUI: works OK.
4) Now use the "Generate Session URL" feature to obtain an URL for that connection that can be used in a script.
You'll notice that the URL does not include a comma at all.
Where the passord is supposed to be (so immediatly after the colon) the first characters are %2C.
After that %2C are all remaining characters of the password (those after the comma) and then the @-character followed by the host etc
5) Using that URL in a script leads to a refused connection caused by bad credentials (which is correct)
6) If the log of the server would show the used password (I guess it won't) then that password would start with "%2C" instead of with ",".


I see two options for what you need to correct:

A) "Generate Session URL" should not URL-encode the password string
B) The script engine should convert the URL-encoded password back before sending it to a sever.

If you go for option B, I suggest adding a security improvement: if the scripting engine has to decode the password anyway, why not make it a bit more secure by really encrypting the passwords in the generated URLs?

I won't be following this up any more since my workaround is working fine.

Thanks for your report.

I'm having no problems with this command:

open sftp://user:%2Ccomma@host/

Please attach a full log file showing the problem (using the latest version of WinSCP).

This is with WinSCP 5.7.5 (build 5665)

I have been given a password (that starts) with a comma ",".
For scripting purposes, I use the "Generate Session URL" feature. The result of which is for example:
sftp://myuser:%2Ccomma@sftp.server.com/dir1/dir2/

In that case the password was
,comma

When using that URL in a script the connection fails, If I adapt the URL to
sftp://myuser:,comma@sftp.server.com/dir1/dir2/
The connection works fine.

So there is a simple workaround, but some people might be get confused over this small bug.

J.