通过将密码作为安全字符串并将其作为加密标准字符串"保存到名为类似名称的文件中，我设法解决了类似的问题"Account.User.pwd" 其中 Account 是与密码关联的帐户名称，User 是生成安全字符串的用户(只有该用户才能解密该文件).

I have managed to get around similar problems by taking the password as a secure string and saving it, as an "encrypted standard string" to a file named something like "Account.User.pwd" where Account is the name of the account associated with the password and User is the user who generated the secure string (only this user will be able to decrypt that file).

这与@Keith 使用的方法非常相似，如果您点击他对上述问题本身的评论中的链接.下面的方法更容易遵循，因为它不直接使用 [System.Runtime.InteropServices.Marshal] 类.

This is pretty similar to the approach used by @Keith if you follow the link in his comment on the question itself above. The approach below is a little easier to follow as it doesn't play directly with the [System.Runtime.InteropServices.Marshal] class.

将密码从文件内容转换回更复杂，但这里是一个逐步完成该过程的示例:

Converting the password back from the contents of the file is more involved, but here is an example that steps through the process:

# Create credential object by prompting user for data
$Credential = Get-Credential

# Encrypt the password to disk
$Credential.Password | ConvertFrom-SecureString | Out-File Account.User.pwd

# Now to read it back again...
$SecureString = Get-Content Account.User.pwd | ConvertTo-SecureString

# Create credential object programmatically
$NewCred = New-Object System.Management.Automation.PSCredential("Account",$SecureString)

# Reveal the password!
$NewCred.GetNetworkCredential().Password

关于这种方法的想法:

1. 抵制在最后一步将密码转储到变量中的诱惑，以防止它在内存中(以明文形式)徘徊，直到变量被丢弃.每次从 PSCredential 转换都不需要花费太多的输入时间.
2. 只有生成文件的用户才能读取它；如果多个用户需要访问共享帐户的密码，则每个用户都必须生成这样的文件(因此建议使用文件命名).
3. 这不需要仅限于密码.您想要加密到磁盘的任何字符串都可以用作原始凭证对象中的密码".数据库连接字符串，尤其是.那些有用户名和密码的人，请记住...
4. 使用文件系统安全/ACL 将不需要的人锁定在密码文件之外.
5. 在磁盘上有一个带有密码的文件，即使它是一个加密的字符串，也可能不符合人们的喜好.没有使用第三方密码管理系统，这是对仅使用明文文件的文件系统安全性的明显改进.你知道它会发生......

1. Resist the temptation to dump the password into a variable at the final step to prevent it hanging around in memory (in cleartext) until the variable is trashed. It doesn't cost much typing to convert from the PSCredential each time.
2. Only the user who generates the file can read it; if multiple users need access to the password for a shared account, each will have to generate such a file (hence the suggested file naming).
3. This doesn't need to be limited to just passwords. ANY string you want to encrypt to disk could be used as the "password" in the original credential object. Database connection strings, esp. those with username and passwords in them, come to mind...
4. Use file-system security/ACLs to lock unwanted people away from the pwd file.
5. Having a file on disk with a password, even if it is an encrypted string, may not be to people's liking. Short of using a third-party password management system, this is a distinct improvement on using only file-system security with a clear-text file. You know it happens...

更多信息:

• ConvertFrom-SecureString
• ConvertTo-SecureString
• PSCredential 类
• 系统.Runtime.InteropServices.Marshal 类
• PowerShell 的 ConvertFrom-SecureString -key 有多安全立>

powershell credentials securestring