объекты.

тавьте, что у нас есть программа или скрипт, который может принимать аргумент пароля (или другую конфиденциальную информацию):

> program.exe /password:secret

Для Linux лучшая практика обычно рекомендуетпротив указание пароля непосредственно в командной строке из-за потенциальных проблем безопасности (пароль может появиться в файле истории оболочки и в таблице процессов системы):

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

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

Однако при поиске я не вижу такой же активной рекомендации для Windows.

При написании программ и скриптов дляWindowsДолжны ли мы предоставить альтернативные средства для ввода пароля помимо аргумента параметра командной строки, чтобы избежать непреднамеренного раскрытия пароля?

Ответ наэтот вопрос предполагает, что специальная подсказка для ввода пароля повышает безопасность, предотвращая серфинг в плечах. Существуют ли другие способы использования видимого пароля в командной строке, который оправдывает написание альтернативных методов ввода, как в контексте оболочки, так и в способе управления процессами Windows?

Меняются ли последствия для безопасности при запуске программы из пакетного файла или сценария PowerShell, который передает пароль в качестве аргумента программе?

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

редактировать - Я понимаю, что мы можем неверно истолковать этот вопрос как основанный на мнении, потому что я упоминаю «лучшие практики» и «рекомендации», чтобы предоставить справочную информацию. Однако я ищу конкретные доказательства того, как пароль может быть уязвим в аргументе команды, и - если это предположение верно - конкретные примеры или ссылки, которые изображают безопасные альтернативы.

 TheIncorrigible131 окт. 2017 г., 18:59
Ваш текстовый пароль будет отображаться вShow-History или используя стрелки вверх / вниз в сеансе. «Лучшая практика» - использовать DPAPI (securestring) или полагаться на аутентификацию из Windows.

Ответы на вопрос(2)

briantistотличный ответ:

Когда безопасность является проблемой,не вводите и не запрашивайте пароли или другие конфиденциальные данные в качестве аргументов командной строки, Другие пользователи и программы могут тривиально отслеживать аргументы командной строки.

Мы можем использоватьИнструментарий управления Windows получить аргументы командной строки в PowerShell и с помощью других программ, подобных темпостроен на .NET, Вот пример использования PowerShell:

PS> Get-WmiObject Win32_Process -Filter 'Name = "program.exe"' | Select-Object CommandLine

C:\program.exe /password:secret

Аргумент пароля командной строки также отображается в диспетчере задач для всех пользователей в той же системе, которые могут видеть процессы других пользователей:

Как написал в своем ответе briantist, программы и сценарии, которые мы пишем, должны предоставлять альтернативные средства для ввода конфиденциальной информации помимо аргументов командной строки. Сценарии PowerShell могут безопасно передавать эту информацию между сценариями, используяPSCredential или жеSecureString объекты.

Решение Вопроса

только внутри сеанса. Это было верно для командной строки и для PowerShell.

КакБилл Стюарт Как указывалось выше, Windows PowerShell в Windows 10 и Windows 2016 по умолчанию включает PSReadline, который сохраняет историю команд между сеансами. Вы можете увидеть это, посмотрев файл здесь:(Get-PSReadLineOption).HistorySavePath.

Но даже если он отключен или в версии ОС, которая не предлагает такой опции, это не означает, что ввод открытого текста в качестве аргумента является хорошей идеей.

Если вы должны предложить это, выдолжен также есть способ получить приглашение программы во время выполнения.

Для PowerShell и других приложений .Net у вас есть еще одна проблема с принятием незашифрованных паролей: они сохраняются в памяти, и нет хорошего способа их явной очистки.

Эта проблема двоякая: строки являются неизменяемыми в .Net, что означает, что вы не можете просто изменить строку пустыми или случайными символами, чтобы очистить ее в памяти (вы на самом деле создадите совершенно новую строку), и, кроме того, вы не может контролировать, когда конкретный объект будет обрабатываться сборщиком мусора, поэтому вы не можете явно удалить его.

Вот почемуSecureString класс существует, но не все могут использовать это.

В PowerShell естьPSCredential объект который хранит имя пользователя в виде простого текста и пароль в видеSecureString, Это всегда должно использоваться в PowerShell и должно быть предпочтительным типом аргумента (вместо отдельного имени пользователя и пароля).

Большинство команд в PowerShell, для которых требуются учетные данные, принимают его как объект этого типа.

С помощью этого объекта вы также можете легко получить незашифрованную версию пароля. Затем это помещается в управляемую строку, и вы получаете риски, о которых я упоминал выше.

На мой взгляд, все же предпочтительнее использоватьPSCredential возражать в этих ситуациях, вплоть до того момента, пока вам не понадобится текстовая версия. Это помогает поддерживать стандартизацию этого типа как во встроенной / «официальной» емкости, так и в пользовательских командах.

Этот тип также легко сериализуем сExport-Clixml в форме, которая зашифрована.Это может дать вам действительно хороший способ предоставить автоматизированную возможность использовать сохраненные учетные данные в сценариях, без текста в незашифрованном виде, без запроса или вмешательства пользователя..

 Bill_Stewart31 окт. 2017 г., 23:16
Ответ - нет, потому что, если пароль является открытым текстом в командной строке, то по определению в определенный момент он является открытым текстом в памяти. Если отправляющая и получающая программы старательно перезаписывают текстовую строку в своей памяти процессабыстро, то эта уязвимость, вероятно, довольно мала.
 briantist31 окт. 2017 г., 20:07
@Bill_Stewart спасибо за это. Путь установлен, файл там,.HistorySaveStyle установлен вSaveIncrementallyи файл содержит историю. Когда я закрыл все свои окна PowerShell и снова открыл одно, у него действительно была некоторая история, но это совсем не возвращалось назад. Максимум день или два. Также история не показывает сh так что это меня смутило. Во всяком случае, я должен отредактировать этот материал в.
 Bill_Stewart31 окт. 2017 г., 20:00
Интересно. Ты уверен? Попробуйте запустить(Get-PSReadLineOption).HistorySavePath.
 Bill_Stewart31 окт. 2017 г., 19:35
«Windows не сохраняет историю команд между сеансами» - к вашему сведению, это уже не тот случай, если используется модуль PowerShell PSReadline, в котором хранится файл истории команд (а PSReadline установлен и активен по умолчанию в Windows 10 / Server 2016 и предположительно новее ).
 briantist02 нояб. 2017 г., 00:00
Что сказал @Bill_Stewart, с оговоркой, что в управляемой памяти (в .Net), выне можешь перезаписать текстовую строку быстро (или надежно). Если ни отправляющая, ни принимающая программы не являются управляемыми приложениями, то они могут это сделать. Теоретически, управляемые приложения могут также хранить строку в неуправляемой памяти и, возможно, вызывать API для запуска процесса.

Ваш ответ на вопрос