Powershell is frequently described as secure by default or design, but I’ve found that end-users could be frequently tempted to take risks or bypass the security or not aware of what the implications are.
Nothing really new to most developers or sysadmins, but not many of them have gone through the process of decoding a SecureString, even if is quite a trivial exercise.
Just a simple example :
$cred = Get-Credential #type username and password when prompted
The $Cred ($PSCredential)object shows the username in clear text and protects the password saving it within a SecureString object. What we think that object secure, right? Unfortunately, it’s not so secure!
Under that session can be decoded or de-crypted with this simple oneliner that I’ve declared in a function to make it easier to use.
Tries to decode a SecureString and returns its clear text value
Tries to decode a SecureString from a PSCredential Object and returns its clear text value
get-credential | Decode-SecureStringPassword
get-credential | dssp
Decode-SecureStringPassword -password SecureString
.AUTHOR [email protected] , 2018 https://www.scriptinglibrary.com
# Param1 help description
Are you curious to reveal your password? After running the previous script is simple as that:
$cred | dssp # or $cred | Decode-SecureStringPassword
secret # this is the password in clear-text that I've typed!
Remember that all $cred (Get-Credential) variables protect your password with a SecureString object and this should be treated very carefully and deleted as soon are not required any more because can be decoded or de-crypted under the same powershell session or within the same user context.
In the next post we will talk how to store the credentials, usually required for automation or scheduled tasks.