在 Windows 命令中使用密码参数安全吗？

想象一下，我们有一个程序或脚本可以接受密码（或其他敏感信息）参数：

> program.exe /password:secret

对于 Linux，最佳实践通常建议against出于潜在的安全考虑，直接在命令行上指定密码（密码可能出现在 shell 的历史文件和系统的进程表中）：

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

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

然而，在四处搜索时，我没有看到针对 Windows 的同样有力的推荐。

编写程序和脚本时Windows，除了命令行选项的参数之外，我们是否应该提供另一种输入密码的方法，以避免无意中泄露密码？

答案是这个问题建议专门的密码输入提示通过防止肩窥来提高安全性。是否有其他方法可以利用命令字符串中的可见密码来证明编写备用输入方法的合理性，无论是在 shell 上下文中还是在 Windows 管理进程的方式中？

从批处理文件或将密码作为参数传递给程序的 PowerShell 脚本启动程序时，安全隐患是否会发生变化？

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

Edit- 我知道我们可能会将此问题误解为基于意见，因为我提到“最佳实践”和“建议”来提供背景。然而，我寻求具体的证据来证明密码如何在命令参数中容易受到攻击，并且如果这个假设有效的话，我会寻找描述安全替代方案的具体示例或参考资料。

Windows 历史上不保存会话之间的命令历史记录，仅保存会话内的命令历史记录。对于命令提示符和 PowerShell 来说都是如此。

As 比尔·斯图尔特指出，Windows 10 和 Windows 2016 上的 Windows PowerShell 默认包含 PSReadline，它确实会保存会话之间的命令历史记录。您可以通过查看此处的文件来看到这一点：(Get-PSReadLineOption).HistorySavePath.

但即使它被设置为关闭，或者在不提供该选项的操作系统版本上，这并不意味着输入明文密码作为参数是一个好主意。

如果你必须提供这个，你should还有一种方法可以让程序在运行时提示。

对于 PowerShell 和其他 .Net 应用程序，接受明文密码时还会遇到另一个问题：它们会保留在内存中，并且没有好的方法可以显式清除它们。

这个问题有两个方面：字符串在 .Net 中是不可变的，这意味着您不能只用空值或随机字符修改字符串以将其清除在内存中（您实际上将创建一个全新的字符串），最重要的是您无法控制垃圾回收何时处理特定对象，因此您无法显式删除它。

这就是为什么SecureString class存在，但并不是所有东西都可以使用它。

在PowerShell中，有一个PSCredential object它以纯文本形式存储用户名和密码SecureString。这应该始终在 PowerShell 中使用，并且应该是首选参数类型（代替单独的用户名和密码）。

PowerShell 中需要凭据的大多数命令都将其视为此类对象。

您还可以使用此对象轻松检索密码的明文版本。这样做然后将其放入托管字符串中，您就会面临我上面提到的风险。

但在我看来，最好还是使用PSCredential对象在这些情况下，直到您需要纯文本版本。它有助于在内置/“官方”功能以及用户定义的命令中保持这种类型的标准化。

这种类型也很容易序列化Export-Clixml转换为加密的形式。这可以为您提供一种非常好的方法，提供在脚本中使用存储的凭据的自动化选项，无需任何明文内容，也无需提示或用户干预.