How do I avoid saving usernames and passwords in P

Question

So basically I want to write a Powershell script which will export the last 1days worth of Backup Logs for Windows Server Backup, format the info into a nice little table, then SMTP send it to an external location outside of the customers local Exchange. I have a smarthost I can use for this purpose, and the credentials etc.

But I don't want to store the UN and Password in the Powershell in plain text, or have the script running using the credentials in plain text.

Is there a way around this?

Cheers!

Answer 1

I have managed to get around similar problems by taking the password as a secure string and saving it, as an "encrypted standard string" to a file named something like "Account.User.pwd" where Account is the name of the account associated with the password and User is the user who generated the secure string (only this user will be able to decrypt that file).

This is pretty similar to the approach used by @Keith if you follow the link in his comment on the question itself above. The approach below is a little easier to follow as it doesn't play directly with the [System.Runtime.InteropServices.Marshal] class.

Converting the password back from the contents of the file is more involved, but here is an example that steps through the process:

# Create credential object by prompting user for data
$Credential = Get-Credential

# Encrypt the password to disk
$Credential.Password | ConvertFrom-SecureString | Out-File Account.User.pwd

# Now to read it back again...
$SecureString = Get-Content Account.User.pwd | ConvertTo-SecureString

# Create credential object programmatically
$NewCred = New-Object System.Management.Automation.PSCredential("Account",$SecureString)

# Reveal the password!
$NewCred.GetNetworkCredential().Password

Thoughts about this approach:

1. Resist the temptation to dump the password into a variable at the final step to prevent it hanging around in memory (in cleartext) until the variable is trashed. It doesn't cost much typing to convert from the PSCredential each time.
2. Only the user who generates the file can read it; if multiple users need access to the password for a shared account, each will have to generate such a file (hence the suggested file naming).
3. This doesn't need to be limited to just passwords. ANY string you want to encrypt to disk could be used as the "password" in the original credential object. Database connection strings, esp. those with username and passwords in them, come to mind...
4. Use file-system security/ACLs to lock unwanted people away from the pwd file.
5. Having a file on disk with a password, even if it is an encrypted string, may not be to people's liking. Short of using a third-party password management system, this is a distinct improvement on using only file-system security with a clear-text file. You know it happens...

More information:

• ConvertFrom-SecureString
• ConvertTo-SecureString
• PSCredential class
• System.Runtime.InteropServices.Marshal class
• How secure is PowerShell's ConvertFrom-SecureString -key

powershell credentials securestring