Provide Method for Saving Secrets in different format e.g. base64 encoded

[PaulBendall]

Use case : Programmatically accessing Azure DEVOps is through the use of Personal Access Tokens (PAT). The PAT has to be base64 encoded when constructing the auth. header.

Can the Get/Set-Secret cmdlets improve security when dealing with Personal Access Tokens, for example GitHub and Azure DEVOps, as well as other API that require the parsing of an authentication header? Having the text in insecure memory for as short a time as possible would be beneficial.

At the moment I'm using the Set-Secret to save the encoded base64 PAT but that still means variables that are potentially unsafe and need properly handling in memory. At least being able to pull the value from the store means I'm not having to manipulate it every time I call it out of credential manager. Now I just need to worry about auth. header variable and securely destroying that after use.

[JustinGrote]

Not sure what you mean, all keys are securestrings, and base64 is a string, so you can just save it in its base64 format with set-secret and then retrieve it as a securestring with get-secret and pass it along all while remaining "secure" in memory though the security of SecureString is debatable.

So if you get a PAT, you can convert it to base64 before saving it with set-secret, then when you get-secret, it'll be in the format you expect.

I don't think it's in the purview of the module to do the type conversions, it would have to briefly "unsecure" the secret anyways to do the conversion, so it's no different than you doing it yourself.

[PaulBendall]

@JustinGrote the problem is that by leaving it to the user you end up with people not clearing variables & sessions correctly. The more the module can do securely and following best practice then there are fewer chances secrets can be exploited