No it's "don't use this thing which doesn't do what it says on the tin and is therefore a foot gun." Something that is obviously insecure will be treated with more caution / put on the correct side of the authorization boundary compared to something that claims to be.
> "obviously insecure will be treated with more caution"
What planet are you from and can I go there?
SecureString provides one layer in the "defence in depth". If someone accidentally logs it, then it won't leak. If it is used as a script parameter, then the prompt will use password input characters automatically.
Seriously, I want you to try this PowerShell snippet right now. (You can even run it on Linux too with pwsh v7, so no excuses!):
PARAM(
[parameter(Mandatory=$true)]
[securestring]$Secret
)
Write-Warning "Oops I didn't mean to log this: $Secret"
$Secret | ConvertTo-Json -Compress
$Secret | Export-Clixml 'accidental serialisation.xml'
Get-Content 'accidental serialisation.xml'
Run the the script and see what happens.
There's even low-level protection built-in, such zeroing out the memory when it is garbage collected (unlike normal strings).
Why is this a bad thing!?
Do you like secrets leaking everywhere unless everyone is always hyper vigilant? Or do you prefer to roll your own half-baked secret storage type that nothing else is compatible with?
PS: The page with that advice is based on an "archived" read-only repo with a bunch of open issues of people befuddled as to why this bad, BAD, BAD advice is being published there.
They're not really a part of "pwsh", the SecureString type is built in to the .NET Framework, and has been before PowerShell existed.
One of the many reasons I detest stringly-typed programming is that many small things become difficult, including (but not limited to) the handling of secrets.
