Imagine que tenemos un programa o script que puede tomar un argumento de contraseña (u otra información confidencial):

> program.exe /password:secret

Para Linux, las mejores prácticas generalmente recomiendanen contra especificando la contraseña directamente en la línea de comandos debido a posibles problemas de seguridad (la contraseña puede aparecer en el archivo de historial del shell y en la tabla de proceso del sistema):

$ ./program.sh --password 'secret' &
[1] 4152

$ cat /proc/4152/cmdline 
/bin/sh./program.sh--passwordsecret

Sin embargo, cuando busco, no veo la misma recomendación vigorosa para Windows.

Al escribir programas y scripts paraVentanas, ¿deberíamos proporcionar un medio alternativo para ingresar una contraseña además de un argumento para una opción de línea de comandos para evitar exponer involuntariamente la contraseña?

La respuesta aesta pregunta sugiere que una solicitud de ingreso de contraseña dedicada mejora la seguridad al evitar el hombro de navegación. ¿Hay alguna otra forma de explotar una contraseña visible en una cadena de comandos que justifique la escritura de métodos de entrada alternativos, tanto en el contexto de un shell como en la forma en que Windows administra los procesos?

¿Cambian las implicaciones de seguridad al iniciar un programa desde un archivo por lotes o un script de PowerShell que pasa una contraseña como argumento al programa?

$password = # prompt for password 
program.exe /password:$password

Editar - Entiendo que podemos malinterpretar esta pregunta como basada en la opinión porque menciono "mejores prácticas" y "recomendaciones" para proporcionar antecedentes. Sin embargo, busco evidencia específica que demuestre cómo una contraseña puede ser vulnerable en un argumento de comando y, si esta suposición es válida, ejemplos concretos o referencias que representan alternativas seguras.