Consider Replacement for SecureString

[CalebAlbers]

PowerShell Core 6.0 runs off of .NET Core. Unfortunately, the .NET Core team has not implemented SecureString support for Linux or MacOS, as SecureString relies on the Windows Data Protection API (DPAPI).

Given it is unlikely that .NET Core will have a non-Windows SecureString implementation any time soon, it would behoove us to consider implementing alternative methods of API key storage. Getting away from the SecureString implementation would allow this module to work on Linux or MacOS implementations. This is especially exciting given AWS Lambda now supports PowerShell (running on Linux).

AES or some other encryption technique would work. For backward compatibility, encrypting with a method other than SecureString would likely be an optional/explicit setting in the module configuration.

The downside would be that AES requires a key to be created/stored, whereas SecureString just relies on the user principal. The upside is that the AES key could be protected by NTFS permissions, which means that we would finally find a more elegant solution to the problem of a user wanting to update the API key that is used for an integration that is invoked by or running under SYSTEM/some other user principal.

I could see a reason to default to AES on MacOS and Linux. Should SecureString be the default for Windows? Surely some logic would need to be added to the function that loads the module config in order to deal with both encryption methods in an intuitive manner.

I'd love to hear input from others on if they have use cases pertaining to this. @adrianwells @gavsto ?

[adrianwells]

@CalebAlbers Maybe the answer is all the above with logic to cover the different scenarios as you suggested. Sorry for the delayed reply. There is also the possibility of PowerShell 6 on Windows where AES may be preferred over SecureString as you suggested for some scenarios.

[adrianwells]

@CalebAlbers Hello. For reference and more reasons to move away from SecureString Problems with SecureString and SecureString shouldn't be used
, quoting the last article, "The general approach of dealing with credentials is to avoid them and instead rely on other means to authenticate, such as certificates or Windows authentication."

[adrianwells]

This may help PowerShell Secrets Management Module

[adrianwells]

Looks like this may now help SecretManagement and SecretStore are Generally Available

[davidhaymond]

@CalebAlbers @adrianwells Since SecretManagement and SecretStore are now available and offer a cross-platform facility for storing secrets in PowerShell, would it make sense to use it on Windows as well as Linux and macOS? If so, would that require a major version bump, or could it be done in a way that is transparent to users?

I have a PowerShell script that I really want to move from Windows to Linux, so I may fork this repo and see if I can get a basic implementation working.

[adrianwells]

@davidhaymond yes sounds like worth exploring. Feel free to fork and submit a PR with an implementation.

[davidhaymond]

After some research, I believe that SecretManagement and SecretStore are not the best solutions for automation at this time. The main reason for this is that SecretStore only supports one store per user (see this GitHub issue). Since the end user might already have a store, we cannot guarantee that it will be passwordless, which is required for background operation since a password-protected store would cause an interactive prompt.

Thus, I think that SecretStore could be used by a system administrator to retrieve an API key to pass to Add-ITGlueAPIKey with each execution, but should not be used internally by ITGlueAPI. In addition, a passwordless store relies on file protections only, which might or might not be an acceptable level of security.

I see a couple of options:

• Disable the ability to export module settings on non-Windows platforms, requiring Add-ITGlueAPIKey to be run each time the module is used. It is the responsibility of the end user to safely store the API key. See also Microsoft's SecureString recommendation.
• Allow exporting module settings and use chmod to set the file permissions to prevent access by other users. Many Linux CLI tools use this approach to save authentication tokens, but it may or may not meet security standards.

Any thoughts?

[davidhaymond]

After more thought and research, I think that we should add support for SecretManagement and SecretStore, but not depend on it exclusively. Even with the current limitations of SecretStore, it is up to the user to configure the vault appropriately. This module can support it as an option while still falling back on existing solutions for backward compatibility.

[davidhaymond]

I've updated my fork with initial cross-platform support. It is backward-compatible with older versions, and simply saves the API key unencrypted with a warning message to the user. For increased security, it would be advisable to add the key each session without running Export-ITGlueModuleSettings so it never gets saved to disk.