Windows 명령에서 암호 인수를 사용하는 것이 안전합니까?

Question

우리가 암호 (또는 기타 민감한 정보)를 인수 걸릴 수있는 프로그램 또는 스크립트가 상상해 : Linux의

> program.exe /password:secret 

을, 가장 좋은 방법은 일반적으로에 대한 명령 줄 때문에 직접 암호를 지정하는 것이 좋습니다 잠재적 인 보안 문제 (암호는 쉘의 기록 파일 시스템의 프로세스 테이블에 나타날 수) : 주변 검색 할 때

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

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

그러나, 나는 Windows 용 같은 활발한 추천을 볼 수 없습니다.

Windows에 대한 프로그램 및 스크립트를 작성할 때 실수로 암호가 노출되는 것을 방지하기 위해 명령 줄 옵션의 인수 외에 암호를 입력 할 수있는 다른 방법을 제공해야합니까?

this question에 대한 대답은 전용 암호 입력 프롬프트가 어깨을 감싸는 것을 방지하여 보안을 향상 시킨다는 것을 나타냅니다. 셸의 컨텍스트와 Windows에서 프로세스를 관리하는 방법에서 대체 입력 방법을 쓰는 것을 정당화하는 명령 문자열에서 보이는 암호를 이용하는 다른 방법이 있습니까?

암호를 프로그램의 인수로 전달하는 배치 파일이나 PowerShell 스크립트에서 프로그램을 시작할 때 보안 관련 내용이 변경됩니까?

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

편집 - 난 우리가이 질문을 잘못 해석 할 수 있음을 이해 의견을 기반 나는 배경을 제공하는 "최상의 방법"과 "추천"을 언급하기 때문이다. 그러나 암호가 명령 인수에서 어떻게 취약 할 수 있는지 보여주는 특정 증거를 찾고 —이 가정이 유효한 대체 사례 인 — 구체적인 예 또는 참조 인 경우이를 찾아야합니다.

Answer 1

Windows는 역사적으로 세션간에 명령 내역을 저장하지 않았습니다. 이것은 명령 프롬프트와 PowerShell에 해당됩니다.

Bill Stewart과 같이 Windows 10 및 Windows 2016의 Windows PowerShell에는 기본적으로 PSReadline이 포함되어 있으므로 세션간에 명령 기록을 저장합니다. 여기에 파일을 보시면 알 수 있습니다 : (Get-PSReadLineOption).HistorySavePath.

하지만 꺼져 있거나 옵션을 제공하지 않는 OS 버전 인 경우에도 일반 텍스트 비밀번호를 입력하는 것은 좋지 않습니다.

제공해야 할 경우 에는 런타임에 프로그램 프롬프트를 표시하는 방법이 있어야합니다.

PowerShell 및 기타 .Net 응용 프로그램의 경우 일반 텍스트 암호를 사용하는 것과 관련하여 또 다른 문제가 있습니다. 메모리에 남아 있기 때문에 명시 적으로 지울 수 없습니다.

이 문제는 두 가지로 나눌 수 있습니다. 문자열은 .Net에서 변경할 수 없습니다. 즉, 문자열을 null 또는 임의의 문자로 수정하여 메모리에서 지우고 (실제로는 새로운 문자열을 생성 함), 그 중에서도 특정 객체가 가비지 콜렉션에 의해 처리되는시기를 제어 할 수 없으므로이를 명시 적으로 제거 할 수 없습니다.

여기에 SecureString class이 있지만 모든 것이 이것을 사용할 수있는 것은 아닙니다.

PowerShell에는 사용자 이름을 일반 텍스트로 저장하고 암호는 SecureString으로 저장하는 PSCredential object이 있습니다. PowerShell에서 항상 사용해야하며, 별도의 사용자 이름과 암호 대신 기본 인수 형식이어야합니다.

자격 증명이 필요한 PowerShell의 대부분의 명령은이 개체 유형으로 간주합니다.

이 개체를 사용하여 일반 텍스트 버전의 암호를 쉽게 검색 할 수 있습니다. 그런 다음 관리 문자열에 넣으면 위에서 언급 한 위험이 발생합니다.

제 생각에는 평문 버전이 필요할 때까지 PSCredential 개체를 사용하는 것이 좋습니다. 내장형/'공식'용량뿐만 아니라 사용자 정의 명령에서도이 유형의 표준화를 유지하는 데 도움이됩니다.

이 유형은 Export-Clixml과 함께 쉽게 직렬화 할 수 있으며 암호화 된 형태로되어 있습니다. This can give you a really nice way of providing an automated option to use stored credentials in scripts, with nothing in plaintext, and no prompting or user intervention required.

Answer 2

더 직접적으로 내 질문에 대답하려면, 여기 briantist의 우수한 대답에 작은 보충입니다 :

보안 우려, 경우 하지 입력 또는 요청 암호 또는 명령 행 인수와 같은 다른 중요한 데이터. 다른 사용자와 프로그램은 명령 줄 인수를 매우 사소하게 기습 할 수 있습니다.

Windows Management Instrumentation을 사용하여 PowerShell 및 built on .NET과 같은 다른 프로그램을 통해 명령 줄 인수를 가져올 수 있습니다. 다음은 그 예 사용 PowerShell을이다 :

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

C:\program.exe /password:secret 

명령 줄 암호 인수는 다른 사용자의 프로세스를 볼 수 있습니다 동일한 시스템에서 모든 사용자를 위해 또한 작업 관리자에서 볼 수 있습니다 :

briantist가 답변을 썼을 때, 우리가 작성한 프로그램과 스크립트는 명령 줄 인수 외에 중요한 정보를 입력하는 대체 수단을 제공해야합니다. PowerShell 스크립트는 PSCredential 또는 SecureString 개체를 사용하여이 정보를 스크립트간에 안전하게 전달할 수 있습니다.