Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There is no possibility to choose a custom file path #77

Open
stevenwobser opened this issue Jul 13, 2021 · 6 comments
Open

There is no possibility to choose a custom file path #77

stevenwobser opened this issue Jul 13, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@stevenwobser
Copy link

There is no possibility to choose a custom file path right now.

This feature would be really useful for team collaboration and automation environments, as the secret store could be checked into a Git repository together with the scripts that require it. This functionality would be similar to Ansible Vault.

@PaulHigin
Copy link
Contributor

SecretStore is designed as a local store and was not intended to be portable. The location of the data files is part of the security, especially if 'no password' option is selected.

However, this is something we can consider as a future enhancement.

@PaulHigin PaulHigin added the enhancement New feature or request label Jul 19, 2021
@ckrueger1979
Copy link

@PaulHigin

Is at least DPAPI used if option set to "no password"?
From a quick look to the source code it seems that only the "Username" is the secret.

@PaulHigin
Copy link
Contributor

Encryption by user name is just a defense in depth effort when storing the actual encryption key to file, to add a layer of obfuscation. For the 'no password' option we basically rely on file system to protect the stored key.

DPAPI was not used because it is Windows only, and also only works well for logged in user accounts but not built-in accounts. We could use DPAPI in AllUsers scope for all accounts, but that is really no better than file system protection.

However, we could special case Windows only platform and log-in accounts and use DPAPI only in these cases. It is something to consider.

@ckrueger1979
Copy link

DPAPI should protect secrets if a laptop is stolen, the filesystem does not protect in that case.
Please rename the option to "no protection at all".

It's really a shame that you implement a no protection option in a secret store!

@PaulHigin
Copy link
Contributor

PaulHigin commented Sep 28, 2021

It's really a shame that you implement a no protection option in a secret store!
You should have BitLocker on in your laptop!

The documentation is clear that the no password option is less secure and that secret protection relies on file system access protections. But it is not 'no protection at all'. The default configuration has the highest security with password option on.

If you only use Windows systems, you can try using the CredMan extension vault.
https://github.com/PowerShell/SecretManagement/tree/master/ExtensionModules/CredManStore

A community member has taken this example extension vault and published it on PSGallery.
https://www.powershellgallery.com/packages/SecretManagement.JustinGrote.CredMan/1.0.0

Also, SecretManagement is extensible so you can create your own extension vault implementation to fit your specific needs.

@ckrueger1979
Copy link

This module is an extension vault module for the PowerShell SecretManagement module. It stores secrets locally using Windows Credential Manager for the current interactive user account context. This module works only for Windows platforms.

That's only working for interactive users. DPAPI is the only viable solution.

The documentation states:

But the key for decryption is stored on file in the current user location, and is less secure.

But it does not state that the file itself is totally unprotected.
I assumed that no one at Microsoft is doing such a bold move.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants