Differences

This shows you the differences between the selected revisions of the page.

guide_protecting_credentials_for_automation 2018-09-18 guide_protecting_credentials_for_automation 2024-04-22 (current)
Line 5: Line 5:
  * The script/code may often need to be accessible on the production system for review or auditing purposes or reuse, while the credentials should not.   * The script/code may often need to be accessible on the production system for review or auditing purposes or reuse, while the credentials should not.
-There is no way to store passwords in script in an encrypted way. In general, it is not possible to encrypt information in a way that still allows for its use in an automatic way. +There is no way to store passwords in script in an encrypted way. In general, it is not possible to encrypt any kind of information in a way that still allows for its use in an automatic way. If WinSCP should be able to decrypt the information, anyone can.((For a real encryption, one needs to use a key. And the key needs to be stored somewhere again. It's the chicken or the egg problem.))
Solution is to separate the credentials from the script/code into a configuration file. While the script/code without explicit credentials can be safely stored into a revision system and be otherwise accessible, the configuration file should be protected as much as possible. Particularly its file permissions should be restricted only to administrators (for writing) and user under which the script/code runs (for reading). The configuration file can also be encrypted, for example with [[wp>Encrypting_File_System|built-in NTFS filesystem-level encryption]]. Solution is to separate the credentials from the script/code into a configuration file. While the script/code without explicit credentials can be safely stored into a revision system and be otherwise accessible, the configuration file should be protected as much as possible. Particularly its file permissions should be restricted only to administrators (for writing) and user under which the script/code runs (for reading). The configuration file can also be encrypted, for example with [[wp>Encrypting_File_System|built-in NTFS filesystem-level encryption]].
Line 13: Line 13:
In [[scripting|script]], you can replace actual credentials with reference to environment variables. You can then call WinSCP from a batch file that sets these variables. The batch file itself then serves as a "configuration file". In [[scripting|script]], you can replace actual credentials with reference to environment variables. You can then call WinSCP from a batch file that sets these variables. The batch file itself then serves as a "configuration file".
-For example, following script (''example.txt''):+For example, the following script (''example.txt'')((Using [[scriptcommand_open#username|''-username'']] and [[scriptcommand_open#password|''-password'']] switches instead of specifying credentials in [[session_url|session URL]], because the switches do not require the values to be [[session_url#special|URL-encoded]].)):
<code winscp> <code winscp>
-open sftp://%USERNAME%:%PASSWORD%@example.com+open -username=%USERNAME% -password=%PASSWORD% sftp://example.com/
... ...
</code> </code>
Line 27: Line 27:
set PASSWORD=mypassword set PASSWORD=mypassword
winscp.com /script=example.txt winscp.com /script=example.txt
 +</code>
 +----
 +Another way is to store the password to a separate file and use [[scriptcommand_open#passwordsfromfiles|''-passwordsfromfiles'']]:
 +<code winscp>
 +open -password=C:\path\password.txt -passwordsfromfiles sftp://username@example.com/
</code> </code>
Line 63: Line 68:
You can also leverage Windows Data Protection API to encrypt the password in the %%XML%% file. You can also leverage Windows Data Protection API to encrypt the password in the %%XML%% file.
-To encrypt the password use ''[[ps>microsoft.powershell.security/convertfrom-securestring|ConvertFrom-SecureString]]'' cmdlet:+If you want to encrypt the password within the configuration file, you can use use ''[[ps>microsoft.powershell.security/convertfrom-securestring|ConvertFrom-SecureString]]'' cmdlet. Put the following code to an ad-hoc script (or an interactive PowerShell console):
<code powershell> <code powershell>
Line 80: Line 85:
</code> </code>
-To decrypt the password, use ''[[ps>microsoft.powershell.security/convertto-securestring|ConvertTo-SecureString]]'' cmdlet and assign the resulting ''[[dotnet>system.security.securestring|SecureString]]'' to ''SessionOptions.SecurePassword'':+To decrypt the password, use ''[[ps>microsoft.powershell.security/convertto-securestring|ConvertTo-SecureString]]'' cmdlet and assign the resulting ''[[dotnet>system.security.securestring|SecureString]]'' to [[library_sessionoptions#securepassword|''SessionOptions.SecurePassword'']], instead of using plain text ''SessionOptions.Password'':
<code powershell> <code powershell>
Line 130: Line 135:
You can also leverage Windows Data Protection API to encrypt the password in the XML file. You can also leverage Windows Data Protection API to encrypt the password in the XML file.
-To encrypt the password use PowerShell ''ConvertFrom-SecureString'' cmdlet:+If you want to encrypt the password within the configuration file, you can use use PowerShell ''ConvertFrom-SecureString'' cmdlet:
<code> <code>

Last modified: by martin