Хранить зашифрованную строку в скрипте

Question

Мне нужно сохранить некоторые учетные данные для SMTP-сервера в моем сценарии, но, естественно, я не хочу, чтобы пароль хранился в открытом тексте.

До сих пор я шифрование пароля, как это:

"password" | ConvertTo-SecureString -AsPlainText -Force | 
    ConvertFrom-SecureString 

и использовать его в сценарии, как это:

$password = "(the long string generated from above command)" 
$username = "Test@testdomain.com" 

$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username,($password | ConvertTo-SecureString) 

Однако при создании $cred объекта я получаю следующее ошибка:

ConvertTo-SecureString : Key not valid for use in specified state.

Answer 1

Снимите ConvertFrom-SecureString и перезагрузите его следующим образом:

$Password = "password" | ConvertTo-SecureString -AsPlainText -Force 
$username = "Test@testdomain.com" 
$cred = New-Object System.Management.Automation.PsCredential($username, $Password) 

Answer 2

ПОЖАЛУЙСТА, ПРОЧТИТЕ внимательно и подумайте над пунктами, прежде чем решите, что это не поможет ОП с его проблемой.

Шифрование пароля с использованием механизмов PS или .NET - это случай «безопасности через неизвестность», если у вас нет надежного метода хранения ключа. (Обычные «надежные методы» - это «то, что я знаю», «то, что я есть» (биометрия), и «что у меня есть».) Но неизвестность - это уровень безопасности, который, по-видимому, просит ОП («естественно, я не хотите, чтобы пароль хранился в открытом тексте »). И нет ничего плохого в этом. Но в отличие от случаев, когда получается некоторая защита от несанкционированного доступа, потому что код скомпилирован, это не так.

Однако безопасность зависит от того, кем считается «атакующий». Если вы имеете дело с паролем, который генерирует текущий пользователь, то текущий пользователь не является злоумышленником. Однако вы имеете дело с паролем, установленным каким-либо другим объектом, но вам нужно, чтобы пользователь использовал его, но не видел его, тогда текущий пользователь является потенциальным злоумышленником. (Пример этого случая: скрипту для присоединения к рабочей станции в домене нужен пользователь с правом набора разрешений домена. Возможно, вы захотите, чтобы пользователь смог присоединиться к домену как часть обработки изображений/повторного изображения своего рабочего стола, но вы не хотите, чтобы его учетная запись пользователя домена имела права на присоединение к домену, поэтому ваш сценарий использует другой набор учетных данных, которые вы не хотите, чтобы пользователь знал). Я предполагаю, что OP спрашивает о случае, когда пароль не назначается пользователем. Остальная часть этого ответа касается этого случая.

Использование методов PS/.NET для шифрования/получения пароля - это «безопасность через неизвестность», потому что злоумышленнику нужно только поставить точку останова непосредственно перед использованием пароля. С именем переменной, как $ password, будет легко найти местоположение для установки точки останова. Обнуление имени переменной (например, вызов переменной пароля $exectionContext, которая является орфографической ошибкой автоматической переменной PS) не будет делать много, если 1) сценарий короткий и/или 2) очевидно, какая команда требует пароль.

Таким образом, вместо того, чтобы шифровать пароль в том, что является достаточно прозрачной и простой в обратном порядке, вы можете получить то, что, возможно, является лучшей защитой, просто будучи сложным в настройке $password (или как вы называете var) до его конечной стоимость. Например, если пароль «нарисуй thE_domain» вы могли бы сделать что-то вроде:

...other script code... 
$windowTitle="Install/deinstaller joint script" 
...other script code... 
$paramName = "-th" 
...other script code... 
$status = "End main" 
...other script code... 
$subTitle = $windowTitle.substring(20,4) 
...other script code... 
$count = 32 
...other script code... 
# Use a regex in the following to make it more obscure 
$fixedStatus = $status -replace "n","_" -replace "o",[string][char]$count 
...other script code... 
# If cmdlet/cmd doesn't support password as a positional parameter then 
# write a function that calls cmdlet/cmd and takes password as positional parm 
cmdlet-that-needs-password "arg value 1" ("$subTitle$paramName"+$fixedStatus) "arg value 3" 
...other script code... 
# extra code at the bottom is important to keep someone from 
# just scrolling to bottom of script to see password being used 
# This extra code could be just dummy code that doesn't really do anything 
# Extra code can be placed throughout the script to make it more obscure 
...other script code... 

Answer 3

Maybe Protect-String с Unprotect-String в модуле Carbon является то, что вы ищете. Я использую его все время и прекрасно работаю.

Carbon - это модуль PowerShell для автоматизации конфигурации компьютеров под управлением Windows 7, 8, 2008 и 2012 годов.