How to handle credentials in PowerShell for unattended tasks?

Hard-coding credentials in script is considered cardinal sin and been the source of countless breaches. No matter, big or small script, no matter if it's protected by ACL or running on a server, where no one else supposed to have access, Credentials SHOULD never be part of the script.

?

What's solution then? Actually, couple of ways

Solution # 1: We can create a XML file with credentials where password would be encrypted using Windows Data Protection API and can be decrypted only under that user credential who encrypted the same and also only on the same machine. Looks complicated? Don't worry, it's just two lines

Get-Credential -Message "Provide credentials" | Export-CliXml -Path "C:\temp\myCred_$($env:USERNAME)_$($env:COMPUTERNAME).xml"

$UserCredential = Import-CliXml -Path "C:\temp\myCred_${env:USERNAME}_${env:COMPUTERNAME}.xml" 

        

Is this secure enough? Yes its reasonably secure since even if someone get hold of this xml file, he would not be able to decrypt it no matter what unless he is on the same machine where this was generated and logged in with the same credential with which it was created.

Solution # 2: This solution makes use of third party module named Credential Manager (can be done natively as well but that would get complicated). You need to install the same module on the machine via PowerShell gallery with usual Install-Module and then below commands can help in storing and retrieving credentials from Windows credential Manager

Install-Module CredentialManager

New-StoredCredential -Target O365 -Credentials (Get-Credential) -Persist LocalMachine

Get-StoredCredential -target O365        

You can even skip the first command and save the credential via following Credential Manager GUI and storing the credentials with some name under Generic Credentials and then calling the same via Get-StoredCredential command. This again, uses the same WDPA security and would be accessible on the same machine and to same user context.

Solution # 3: This is similar to solution # 1 but in this we are encrypting both username and password. Also we are making use of 32 bit key (AES encryption), which would make the credential file portable.

$KeyFile = "c:\temp\my.keyfile"
$key = 0..255 | Get-Random -Count 32 | ForEach-Object { [byte]$_ } | out-file $KeyFile 

# Get the credential object from the user

$cred = Get-Credential
$secureUserName = ConvertTo-SecureString -String $cred.UserName -AsPlainText -Force
$securePassword = $cred.Password
$encryptedUserName = ConvertFrom-SecureString -SecureString $secureUserName -Key 
$key$encryptedPassword = ConvertFrom-SecureString -SecureString $securePassword -Key $key

# Create a custom object with the encrypted username and password$object = [PSCustomObject]@{ 
UserName = $encryptedUserName 
Password = $encryptedPassword
}

# Export the object to an XML file

$object | Export-Clixml -Path "C:\temp\credfile.xml"
$key = Get-Content -Path "C:\temp\keyfile.txt"
$object = Import-Clixml -Path "C:\temp\credfile.xml"

# Decrypt both the username and the password with the key and convert them to secure strings
$encryptedUserName = $object.UserName
$secureUserName = ConvertTo-SecureString -String $encryptedUserName -Key $key
$plainUserName = ConvertFrom-SecureString -SecureString $secureUserName -Key $key -AsPlainText
$encryptedPassword = $object.Password
$securePassword = ConvertTo-SecureString -String $encryptedPassword -Key $key
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $plainUserName, $securePassword        

As you can guess, this is portable but a little bit less safe since someone who knows how to use this and have access to both credential file and key file, would be able to decrypt the same.

Solution # 4: Microsoft did start supporting Secure Vaults SecretManagement and SecretStore are Generally Available - PowerShell Team (microsoft.com) but that would need PowerShell 7 and also need to install two more modules so I would not be covering the same here but if someone really want to explore that way then can follow through the link.