How do I get ReadLineAsSecureString() to accept pipe input? - windows

Question

When I am using cmd and pipe to a powershell which uses ReadLine() to read input, it accepts the pipe input as expected:
C:\Users\ohnob>ECHO hi|powershell -Command "write-host $host.UI.ReadLine()"
hi
hi
However, when am using cmd and pipe to powershell using ReadLineAsSecureString(), it hangs until I type return into the terminal:
C:\Users\ohnob>ECHO hi|powershell -Command "write-host $host.UI.ReadLineAsSecureString()"
I need to read as a secure string (using asterisks) when the session is interactive. But I need to read pipe input when there is pipe input. How do I accomplish this in powershell? I expect I could be able to detect whether or not stdin is a pipe somehow and then conditionally use ReadLine() instead of ReadLineAsSexcureString(), but I don’t know how to get a handle of standard input in powershell—I only get access to this PSHostUserInterface object.
EDIT: To clarify, when I use ReadLineAsSecureString() or ReadLine(), I expect it to read one line from input. That allows it to be used multiple times and the user to provide multiple values to the script. I expect any answers to be drop-in replacements for the functions I use except without the issues that I am trying to avoid. Thanks!

Answer 1

Jeroen Mostert makes some good points in the comments, notably that $host.UI.ReadLineAsSecureString() / Read-Host -AsSecureString presumably by design do not accept pipeline input, for security reasons[1].
Therefore, you must explicitly distinguish between receiving pipeline input and not receiving any:
PowerShell provides access to stdin input piped from the outside via the automatic $Input variable.
$MyInvocation.ExpectingInput generally indicates if pipeline input is present.
If there is pipeline input, pass its first line[2] to ConvertTo-SecureString;
if there isn't, call Read-Host -AsSecureString:
$secStr = if ($MyInvocation.ExpectingInput) {
# Alternatively, use $firstLine = [console]::ReadLine() - thanks, #binki
$firstLine = $($null = $Input.MoveNext(); $Input.Current)
ConvertTo-SecureString -AsPlainText -Force $firstLine
} else {
Read-Host -AsSecureString -Prompt 'Enter secret'
}
As a command line to call from cmd.exe that also outputs the result:
C:>echo hi| powershell -Command "$secStr = if ($MyInvocation.ExpectingInput) { $firstLine = $($null = $Input.MoveNext(); $Input.Current); ConvertTo-SecureString -AsPlainText -Force $firstLine } else { Read-Host -AsSecureString -Prompt 'Enter secret' }l$secStr"
Note, however, that secure strings by design print generically as System.Security.SecureString, so that's all you'll see.
[1] I'm speculating in the absence of documentation on that aspect. Piping a plain-text string to Read-Host -AsSecureString definitely has a greater potential of being insecure: the plain-text string being piped may be persisted that way somewhere and, at least hypothetically, if you use something like MyCustomEcho.exe secret | ..., the process' command line will reflect the secret information.
Either way, passing plain text to ConvertTo-SecureString -AsPlainText is always an option, where the additional need to pass -Force also indicates that PowerShell considers using plain-text input that wasn't typed interactively.
[2] The automatic $Input variable is an enumerator (type ) that enumerates lines from stdin on demand. Indexed access such as $Input[0] is not supported; instead, you must use .MoveFirst() to start the enumeration and then access the .Current property to get the first line. That way, the remaining elements aren't consumed and later use of $Input yields the remaining lines.
The only reason for the $(...) around $null = $Input.MoveNext(); $Input.Current is so that the two statements can be wrapped in a single statement that returns the first line, for conceptual clarity; using $null = $Input.MoveNext() first and $firstLine = $Input.Current is perfectly fine also.