![]() ![]() Node10 provider available for Agent v2.144.PowerShell Functions often need to accept secure strings as or PowerShell credentials (which contain secure strings) as parameters.You can read more about this method at Decrypt PowerShell Secure String Password. $Credential = New-Object -TypeName -ArgumentList "dummyUsername", $securePassword Meanwhile you can create the PSCredential object like this: $Credential.GetNetworkCredential().password In the above case we could do the following to retrieve the decrypted password: Lately I came to know about another way of decoding a SecureString object and that is via the PSCredential object itself. How do you intend to use this tip? UPDATE Return ::ToBase64String(::UTF8.GetBytes($key))Īs you can see, I do get a PSCredential object as a parameter, I decode the password, compose the token string and at the end create a Base64 representation of it. $key = ::Format("", $Credential.UserName, $password) $password = Get-PlainText $Credential.Password This is where decoding a secure string was important.įor completeness I’ll show you other cmdlets I wrote to accomplish this task. ![]() All of my authentication methods are using object to express and move credentials. What is expected by the server is a header in your http request that equals to Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ= where the last string is a Base64 encoded string called token and it is composed of the username and password in the following disposition “username:password”. You may ask yourself, why? When can this be handy? It happened to me to be in need to construct an Authentication Header for Basic access authentication. Now it is sufficient to pass your secure string as a parameter and you will retrieve the plain text behind it. $bstr = ::SecureStringToBSTR($SecureString) Next step was translating the shown code into PowerShell and encapsulating it in a cmdlet. Luckily I came across the following article on MSDN which shows the right way to achieve this and translated it to PowerShell cmdlet. What about getting a plain text out of our SecureString? ![]() We saw till now that we are able to create a SecureString from a plain text, express it as encoded string, and load it back to the SecureString object. If no key is specified, the Windows Data Protection API (DPAPI) is used to encrypt the standard string representation. More info about this you can get directly on Technet site ConvertFrom-SecureString. Once stored, you can retrieve it again by ConvertTo-SecureString -String (Get-Content C:\tmppassword.txt)įor using a custom key for the AES algorithm that is used for encryption by the ConvertFrom-SecureString cmdlet, you can specify it via a Key or SecureKey parameter. Consider the following code: ConvertFrom-SecureString $securePassword | Out-File C:\tmppassword.txt If you need to persist your sensitive data in a text file or in a database, you can leverage ConvertFrom-SecureString cmdlet to transform your SecureString value into an encrypted string. $credential = Get-CredentialĪs you can see, I used a Get-Credential cmdlet to trigger the authentication dialog. This object does expose a property called Password which is of type SecureString. Also you could request it through well known authentication dialog and retrieve the above mentioned PSCredential object. This is a indicated way of retrieving sensitive data if user interaction is required. $securePassword = Read-Host "Please enter the password" -AsSecureString You can achieve that in the following way. With Force parameter you just confirm that you understand the implications of using the AsPlainText parameter and still want to use it.Īnother way of creating a SecureString is to interactively prompt a user for information. Be aware that you need to set two parameters in order to process your plain string correctly, and those are AsPlainText and Force.ĪsPlainText indicates that you are providing a plain text as the input and that variable is not protected. $securePassword = ConvertTo-SecureString –String $password -AsPlainText -ForceĬonvertTo-SecureString will do just that. Luckily this is a trivial task since we have a cmdlet that can help us with that. This implies that you need to transform your string to a SecureString. If you are constructing your object instance you need to provide a SecureString for the password argument in the constructor of just mentioned class. I will describe a couple of “tricks” that can be useful meanwhile working with SecureString objects. If you ever needed to supply a credential object, at example to the Invoke-RestMethod cmdlet, then you for sure came across a SecureString. It is quite common to get across SecureString type in PowerShell.
0 Comments
Leave a Reply. |