4 ms·

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 m

by pxx 5y ago

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.

jiggawatts 5y ago
> "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.
- majkinetor 5y ago
  Absolutely. Secrets are awesome part of pwsh. You also have `Get-Secret` and friends for full blown pass-like solution.
  - jiggawatts 5y ago
    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.

by pxx 5y ago

jiggawatts 5y ago

> "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.

majkinetor 5y ago
Absolutely. Secrets are awesome part of pwsh. You also have `Get-Secret` and friends for full blown pass-like solution.
- jiggawatts 5y ago
  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.