Psreadline: GPO support for HistorySaveStyle & set default HistorySaveStyle to SaveNothing

[ckruegerkpmg]

Hi,

it would be great to have group policy support for HistorySaveStyle.
Saving the History to file is an extremly dangerous feature.

Regularly you will find credentials (passwords or authentication tokens) in the history file.

It would be great to have a group policy template to override HistorySaveStyle.

And please, please change the default HistorySaveStyle to SaveNothing
It should be a deliberate decision to enable saving.

greetings
Carsten

[daxian-dbw]

And please, please change the default HistorySaveStyle to SaveNothing
It should be a deliberate decision to enable saving.

It would be a breaking change that affects many people, as many are depending on the history saving/sharing across sessions.
As for the group policy ask, /cc @theJasonHelmick for comments.

[ckruegerkpmg]

@daxian-dbw
Would it be an option to change the default only for new installations and don't touch it for existing ones?

Would it be possible to allow history sharing within one windows session?
(holding the history only in memory)

[daxian-dbw]

Would it be possible to allow history sharing within one windows session?

Yes, by Set-PSReadLineOption -HistorySaveStyle SaveNothing. The command lines from the same session are kept in the memory, but won't be saved to file.

Would it be an option to change the default only for new installations and don't touch it for existing ones?

This is a breaking change. People expecting "saving to file" to be the default, and thus will be surprised finding the history is not saved.

[ckruegerkpmg]

OK but please discuss it internally if it is a breaking change that should be done in the future

[SeeminglyScience]

OK but please discuss it internally if it is a breaking change that should be done in the future

That would be a pretty disastrously bad breaking change. Most folks don't even know that it's PSReadLine specifically that does that for them. Since this is a very widely used feature, that would result in a ton of "history no longer works" issues on PowerShell/PowerShell and probably feedback hub.

GPO would be good for hardened environments though 👍

[ckruegerkpmg]

Would you consider protecting the history file via DPAPI?
-Disadvantage, not readable via editor
-Advantage, secrets in it are better protected

[daxian-dbw]

The latest PSReadLine module (2.0.4) already has heuristics to filter out command lines with secrets when saving to file. Give that a try and see if it helps.

[ckruegerkpmg]

@daxian-dbw
It's better than nothing
// Pattern used to check for sensitive inputs. private static readonly Regex s_sensitivePattern = new Regex( "password|asplaintext|token|apikey|secret", RegexOptions.Compiled | RegexOptions.IgnoreCase);
But such a simple filter didn't prevent passwords to be stored.

-PAT (short for personal access token)
-pwd (short for password)
-passw
and 100 variants I can't think of, right now ;-)

It's impossible to prevent something like this
$x='abc'
$sec=$x | ConvertTo-SecureString -AsPlainText -Force

[daxian-dbw]

Would you consider protecting the history file via DPAPI?

DPAPI could be useful, but again it will be a breaking change. It's quite common for people to open the history file and look for a command that was used a long time ago. Encrypting the history file will make that no possible, or way harder.

But such a simple filter didn't prevent passwords to be stored.

There will be false positive for sure. It's for filtering out some common ways that leak secrets. It's a heuristic after all.
Again, you can opt out history saving easily. As for group policy, I will let @theJasonHelmick chime in.

[ckruegerkpmg]

-Encrypt the history with DPAPI based64 encoded.
-Add a cmdlet that prints the history in cleartext, something like Get-PSReadlineHistory
-And add in line number one of the history file a comment that tell the user to use Get-PSReadlineHistory
Is that reasonable enough, even if it's a breaking change?

I understand that strictly speaking the history file is no security bug but it endangers users.
The history file copies real bad unix practices.