Filter sensitive history items and avoid writing them to the history file

[daxian-dbw]

Fix #934

Detect sensitive history items by using the regex "password|asplaintext|token|key|secret" suggested by Lee.

For sensitive history items, we still keep them in the history queue, so they are still accessible within the same session.
However, we don't write them to the history file, so they will be gone when the session ends, just like the built-in powershell history.

This is done by adding a default handler to AddToHistoryHandler. Quoted from the updated doc for -AddToHistoryHandler:

Specifies a ScriptBlock that can be used to control which commands get added to PSReadLine history,
and whether they should be saved to the history file.

The ScriptBlock is passed the command line, and it is expected to return either a Boolean value,
or an enum value of the type [Microsoft.PowerShell.AddToHistoryOption].
The enum type AddToHistoryOption has 3 members: SkipAdding, MemoryOnly, and MemoryAndFile.

If the ScriptBlock returns $true, it's equivalent to AddToHistoryOption.MemoryAndFile.
The command line is added to the in-memory history queue and saved to the history file.
If the ScriptBlock returns $false, it's equivalent to AddToHistoryOption.SkipAdding,
and the command line is not added to history at all.

If the ScriptBlock returns AddToHistoryOption.MemoryOnly, then the command line is added to the in-memory history queue,
but will not be saved to the history file.
This usually indicates the command line has sensitive content that should not be written to disk.

PSReadLine provides a default handler to this option:
[Microsoft.PowerShell.PSConsoleReadLine]::GetDefaultAddToHistoryOption(string line)
The default handler attempts to detect sensitive information in a command line by matching with a simple regex pattern:
"password|asplaintext|token|key|secret"
When successfully matched, the command line is considered to contain sensitive content, and MemoryOnly is returned.
Otherwise, MemoryAndFile is returned.

To turn off the default handler, just set this option to $null.

[SteveL-MSFT]

Have PSReadLineOption to opt out

[daxian-dbw]

I think it’s useful to keep the sensitive commands in memory, so it can be recalled in the same session. After all, they will be kept in PowerShell’s history buffer anyways. Thanks, Dongbo

________________________________ From: Jason Shirk <[email protected]> Sent: Thursday, September 19, 2019 2:13:11 PM To: PowerShell/PSReadLine <[email protected]> Cc: Dongbo Wang <[email protected]>; Author <[email protected]> Subject: Re: [PowerShell/PSReadLine] Filter sensitive history items and avoid writing them to the history file (#1058) @lzybkr commented on this pull request.

________________________________ In PSReadLine/Cmdlets.cs<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPowerShell%2FPSReadLine%2Fpull%2F1058%23discussion_r326386229&data=02%7C01%7Cdongbow%40microsoft.com%7Cb1a5763b2b8d4163e86208d73d462da7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045243928175672&sdata=EA%2B9CgsZNKe4%2FbDv28OfAenIS%2BYCdXU91VWFwmoALhI%3D&reserved=0>:

HistoryNoDuplicates = DefaultHistoryNoDuplicates;

+ ScrubSensitiveHistory = DefaultScrubSensitiveHistory; Maybe we don't need a new option at all - instead creating a default AddToHistoryHandler. I guess I'm not sure it's useful to keep sensitive command lines in memory but not on disk. After all, password managers clear the clipboard after a short period. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPowerShell%2FPSReadLine%2Fpull%2F1058%3Femail_source%3Dnotifications%26email_token%3DAAA7DWV3MKG2U237Q5OV4IDQKPTOPA5CNFSM4IYDF4N2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCFK7QGQ%23discussion_r326386229&data=02%7C01%7Cdongbow%40microsoft.com%7Cb1a5763b2b8d4163e86208d73d462da7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045243928175672&sdata=T5hNXgGmXvnb%2F1Ar%2FzHc%2FJ%2FLG0dcirVs8IlaxFuLmm4%3D&reserved=0>, or mute the thread<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAA7DWXSOCRNKDSGWA3KVP3QKPTOPANCNFSM4IYDF4NQ&data=02%7C01%7Cdongbow%40microsoft.com%7Cb1a5763b2b8d4163e86208d73d462da7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637045243928185665&sdata=gcSP0CCSHd5NWbPq2RDYiN0EPQA41%2FEQNc7z3kUx7ak%3D&reserved=0>.

[lzybkr]

It would be generally useful for the AddToHistoryHandler to be capable of specifying where a command should be saved, in memory, in a file, both, or neither.

This would require a signature change to AddToHistoryHandler, but I think that could be done without really breaking anything because the primary scenario is binding a script block and those aren't strongly typed. If the delegate expects object, we can have dynamic code testing the object type to support bool and this new enum.

[daxian-dbw]

With a default handler for AddToHistoryHandler, once a user changes the handler, how can he/she set it back to the default? Casting a method to a delegate is supported in PS Core, but not in windows powershell. When the handler is null, it should mean "don't do add-to-history" filtering, not using the default handler.
Being unable to reset the handler feels broken to me.

[lzybkr]

Does save and restore not work?

$handler = (Get-PSReadLineOption).AddToHistoryHandler
...
Set-PSReadLineOption -AddToHistoryHandler $handler

[daxian-dbw]

Well, that DOES work 😄

[vexx32]

Is it worth adding a Reset-PSReadLineOption for things like this?

[daxian-dbw]

Added a public static property PSConsoleReadLineOptions.DefaultAddToHistoryHandler to hold the default handler delegate.

[daxian-dbw]

@lzybkr Code has been updated, can you please take another look?

[lzybkr]

It'd be good to get some more feedback on this design, but I approve.

[daxian-dbw]

@SteveL-MSFT Can you please review again? Thanks!

[daxian-dbw]

@SteveL-MSFT Would you like to take another look?