should this be marked as rc.1-consider milestone?

Need to update PR based on @PowerShell/powershell-committee decision that -Force on ConvertTo-SecureString shouldn't be mandatory

Codacy appears to be wrong, VSCode complains if I remote the assignment since the finally block may use an unassigned variable.

I think removing the hard requirement for -Force when using ConvertTo-SecureString -AsPlainText is a bad idea. I also think ConvertFrom-SecureString -AsPlainText should require -Force to use it.

The reason is really simple: someone looking for how to perform such a task in PowerShell is -Forced to consider the ramifications/risk and think twice about what they are trying to do (there may be a more secure way to do so).

Ease of use is less important than guiding scripters towards a better understanding of the security implications when working with plain-text passwords in scripts.

People are lazy. Make it too easy for them, and they'll take the easy way without thinking about why they shouldn't do that.

Also, FWIW, if the @PowerShell/powershell-committee thinks -Force shouldn't be mandatory in this case, I would like that put in front of the PowerShell Community at large via an RFC rather than just forced in quietly.

What's the point on non-Windows platforms where "SecureString" is a bit of a lie anyway? Requiring -Force on those platforms would be misleading IMO because those strings aren't really that secure. See https://docs.microsoft.com/en-us/dotnet/api/system.security.securestring?view=netcore-3.0#HowSecure and the recommendation to not use this type anymore: https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md

That said, once we get the Secrets management module, I don't see the *-SecureString cmdlets being that useful anymore.

guiding scripters towards a better understanding of the security implications guiding scripters towards a better understanding of the security implications

Wouldn't PSScriptAnalyzer serve this purpose better?

SecureString Class (System.Security)

Represents text that should be kept confidential, such as by deleting it from computer memory when no longer needed. This class cannot be inherited.

GitHub

dotnet/platform-compat

Roslyn analyzer that finds usages of APIs that will throw PlatformNotSupportedException on certain platforms. - dotnet/platform-compat

What's the point on non-Windows platforms where "SecureString" is a bit of a lie anyway? Requiring -Force on those platforms would be misleading IMO because those strings aren't really that secure. See https://docs.microsoft.com/en-us/dotnet/api/system.security.securestring?view=netcore-3.0#HowSecure and the recommendation to not use this type anymore: https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md

In my mind it's not about SecureString and whether or not it is a bit of a lie since you can pull the text out of the string using APIs. It's about interactions between PowerShell and other things -- files on disk, credentials being sent in plain text over a connection, etc. Raising awareness of the potential risk with those type of activities is helpful, as is discouraging use of secrets in plain text.

That said, once we get the Secrets management module, I don't see the *-SecureString cmdlets being that useful anymore.

Agreed.

guiding scripters towards a better understanding of the security implications guiding scripters towards a better understanding of the security implications

Wouldn't PSScriptAnalyzer serve this purpose better?

PSScriptAnalyzer could and should raise warnings for various things related to plain text passwords, but that's only helpful if folks use PSSA. In my opinion, from a security/awareness perspective, pairing -AsPlainText with -Force is helpful.

My motivation for adding this capability is specifically for Secrets Management module. Secrets Management will always return a SecureString type. You would use this cmdlet to convert to plain text, if needed. As for -Force, the discussion in @PowerShell/powershell-committee is that the noun SecureString is already an indicator that care should be taken when using these cmdlets. The user already has to specify -AsPlainText to get plain text. Having them also add a superfluous -Force is unnecessary and just adds to annoyance or worst invites users to add Force = true in PSDefaultParameters.

Secrets Management will always return a SecureString type

Even though the CoreFx team is clearly recommending not to use this type for new development?

@rkeithhill Until corefx provides a SensitiveString type to replace SecureString, we still need a type that doesn't implement ToString() and dump the contents accidentally to a transcript or the screen. And it doesn't make sense for PowerShell to define its own type for this purpose.

As for -Force, the discussion in @PowerShell/powershell-committee is that the noun SecureString is already an indicator that care should be taken when using these cmdlets. The user already has to specify -AsPlainText to get plain text. Having them also add a superfluous -Force is unnecessary and just adds to annoyance or worst invites users to add Force = true in PSDefaultParameters.

For the uncommon occurrence where you want to convert plain text into a SecureString, requiring -Force isn't superfluous. It's a safety precaution -- a reminder to think twice about what you're doing. And it only requires 6 extra characters.

When you say it's unnecessary and just adds to annoyance or invites users to add $PSDefaultParameterValues['ConvertTo-SecureString:Force'] = $true, do you have evidence that users are really annoyed by this or using $PSDefaultParameterValues to do that? There are zero open/closed issues in this GitHub repository complaining about ConvertTo-SecureString requiring -Force when it is used with -AsPlainText. Plus, when it comes to $PSDefaultParameterValues, by the time a user would apply a default value to change the way they invoke ConvertTo-SecureString when working with it interactively, they're likely knowledgeable enough that we should have no problem with them making that decision if they want to. I'm sure -Force might annoy a few people who don't want the reminder. I've spoken with others who appreciate the cmdlet drawing their attention to what they're doing.

@rkeithhill Until corefx provides a SensitiveString type to replace SecureString, we still need a type that doesn't implement ToString() and dump the contents accidentally to a transcript or the screen...

...or into a file as a stored secret, or pull plain text from a file to use as a secret. -Force in these scenarios helps discourage such accidents.

IMHO the change in behavior of -Force is out of scope for this PR, unjustified, and undesirable.

@TravisEz13 Is this ready to merge?

🎉v7.0.0-rc.1 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes