You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 22, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 22, 2026. It is now read-only.
There is no possibility to choose a custom file path #77
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.
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.
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.
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.
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.
Activity
PaulHigin commentedon Jul 19, 2021
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.
ckrueger1979 commentedon Sep 27, 2021
Paul Higinbotham (@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 commentedon Sep 27, 2021
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
AllUsersscope 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 commentedon Sep 28, 2021
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 commentedon Sep 28, 2021
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 commentedon Sep 28, 2021
That's only working for interactive users. DPAPI is the only viable solution.
The documentation states:
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.