É seguro usar um argumento de senha em um comando do Windows?
Imagine que temos um programa ou script que pode receber um argumento de senha (ou outras informações confidenciais):
> program.exe /password:secret
Para Linux, as práticas recomendadas geralmente recomendamcontra especificando a senha diretamente na linha de comando devido a possíveis problemas de segurança (a senha pode aparecer no arquivo de histórico do shell e na tabela de processos do sistema):
$ ./program.sh --password 'secret' &
[1] 4152
$ cat /proc/4152/cmdline
/bin/sh./program.sh--passwordsecret
No entanto, ao pesquisar ao redor, não vejo a mesma recomendação vigorosa para o Windows.
Ao escrever programas e scripts parajanelas, devemos fornecer um meio alternativo para inserir uma senha além de um argumento em uma opção de linha de comando para evitar a exposição involuntária da senha?
A resposta paraessa questão sugere que um prompt de entrada de senha dedicado aprimore a segurança, impedindo a navegação no ombro. Existem outras maneiras de explorar uma senha visível em uma cadeia de comandos que justifique a escrita de métodos de entrada alternativos, tanto no contexto de um shell quanto na maneira como o Windows gerencia processos?
As implicações de segurança mudam ao iniciar um programa a partir de um arquivo em lotes ou script do PowerShell que passa uma senha como argumento para o programa?
$password = # prompt for password
program.exe /password:$password
Editar - Entendo que podemos interpretar mal essa pergunta como baseada em opiniões, porque mencionei as "melhores práticas" e as "recomendações" para fornecer informações básicas. No entanto, busco evidências específicas que demonstrem como uma senha pode ser vulnerável em um argumento de comando e - se essa suposição for válida - exemplos ou referências concretas que descrevem alternativas seguras.