SessionOptions works in this respect the same way as native .NET NetworkCredential (it also has Password and SecurePassword properties).
The issue is that just by returning SessionOptions the password is in plain view. Should you wish to make use of the information within SessionOptions for things such auditing, logfiles or pass the object to another process you have to be careful how to handle the object so not to expose the password value by other means. It's all about reducing the risk.
I'm still not sure I understand.
So what do you propose?
The issue is that just by returning SessionOptions the password is in plain view. Should you wish to make use of the information within SessionOptions for things such auditing, logfiles or pass the object to another process you have to be careful how to handle the object so not to expose the password value by other means. It's all about reducing the risk.
I'm a little concerned about this too. I've been looking into different parameters to make use of and also found that the password is being exposed. It seems a little pointless having a securePassword option and then making the password available to view in SessionOptions.
I'm not sure I understand. Do you mean that you can read the password fromSessionOptions.Password? It that option was not available, what would prevent an attacker from reading the password fromSessionOptions.SecurePassword?
I'm a little concerned about this too. I've been looking into different parameters to make use of and also found that the password is being exposed. It seems a little pointless having a securePassword option and then making the password available to view in SessionOptions.
SessionOptions.Password? It that option was not available, what would prevent an attacker from reading the password from SessionOptions.SecurePassword?
...if I debug the script after the SessionOptions object has been initialized with the SecurePassword, I can see the decoded password as plain text in the Password property of the SessionOptions?
...
I'm a little bit confused by this approach... Yes the password is not stored in the script as plain text, but if I debug the script after the SessionOptions object has been initialized with the SecurePassword, I can see the decoded password as plain text in the Password property of the SessionOptions?
So essentially anyone can pickup my script, run it in debug mode and see the decrypted password?
I feel like I'm missing something here...
param (
$localPath = "F:\Test-Sync01\",
$remotePath = "/Test-Sync01/"
)
try
{
# Load WinSCP .NET assembly
Add-Type -Path "F:\syncapp\WinSCPnet.dll"
# Setup session options
$sessionOptions = New-Object WinSCP.SessionOptions
$sessionOptions.Protocol = [WinSCP.Protocol]::Sftp
$sessionOptions.HostName = "server08"
$sessionOptions.UserName = "syncusr"
$sessionOptions.Password = "BLBALBLA"
$sessionOptions.SshHostKeyFingerprint = "ssh-rsa 1024 13:d3:ef:ee:4d:cc:22:31:04:aa:1e:cd:7b:c7:42:02"
$session = New-Object WinSCP.Session
try
{
# Connect
$session.Open($sessionOptions)
# Synchronize files to local directory, collect results
$synchronizationResult = $session.SynchronizeDirectories(
[WinSCP.SynchronizationMode]::Remote, $localPath, $remotePath, $False)
# Iterate over every download
foreach ($download in $synchronizationResult.Uploads)
{
echo $download.FileName
# Success or error?
if ($download.Error -eq $Null)
{
Write-Host ("Download of {0} succeeded, removing from source" -f
$download.FileName)
try
{
Remove-Item $session.EscapeFileMask($download.FileName)
Write-Host ("Removing of file {0} succeeded" -f
$download.FileName)
}
catch [Exception]
{
Write-Host ("Rmoving of file {0} failed" -f
$download.FileName)
}
}
else
{
Write-Host ("Download of {0} failed: {1}" -f
$download.FileName, $download.Error.Message)
}
}
}
finally
{
# Disconnect, clean up
$session.Dispose()
}
exit 0
}
catch [Exception]
{
Write-Host $_.Exception.Message
exit 1
}