호는 필요악입니다. 오늘날 대부분의 암호 기반 인증 작동 방법인 암호의 길이와 복잡성은 공격자가 사용자를 가장할 때의 어려운 정도와 직접적으로 관련됩니다. 예를 들어, "password"를 암호로 사용하면 공격자는 일반적으로 두 번째 시도에서 이 암호를 알아낼 수 있을 것입니다(첫 번째 시도에는 빈 문자열을 사용할 것임). 무작위로 생성된 6자의 암호(예: 2=w\Z9)를 사용할 경우에도 엔트로피는 40비트보다 작기 때문에 암호 추측(brute-force) 공격에서 2⁴⁰ 이하의 추측으로 암호를 알아낼 수 있습니다. 그러나 시스템이 구현되는 방법에 따라 암호 추측(brute-force) 공격을 피할 수 있는 여지는 있습니다.
  대부분의 웹 사이트는 암호를 일반 텍스트(원래의 암호화되지 않은 형태의 데이터)로 저장하거나 키 없이 해독할 수 있는 Caesar-shift와 같은 간단한 키 없는 "암호"를 사용하여 저장합니다. 심지어 사용자 암호를 암호화하는 사이트조차도 키를 임의의 장소에 저장해야 하며, 웹 서버가 손상되면 이 키가 손상되어 저장된 모든 일반 텍스트 암호가 공개될 수 있습니다. 암호 저장에 권장되는 방법은 암호를 해싱하여 해시 값만 저장하는 것입니다(이 칼럼의 뒷부분에서 다루게 될 솔트 및 스트레치 기술). 이 방법을 사용하면 사이트가 암호를 저장하지 않으므로 암호를 훔칠 수 없지만 사이트는 암호를 해싱하여 저장된 해시 값과 비교함으로써 사용자의 자격 증명을 계속 확인할 수 있습니다.
  무작위로 생성된 매우 긴 암호를 선택하여 모든 곳에서 사용할 경우에도 여전히 중대한 위험에 노출되어 있습니다. 이 경우에 공격자는 보안이 취약한 특정 웹 사이트에서 암호를 알아낸 다음 사용자의 로그인 이름(일반적으로 전자 메일 주소)과 암호를 사용자가 자주 방문하는 다른 사이트에서 사용할 수 있습니다. 또한 특정 사이트의 악의적인 관리자가 사용자의 암호를 사용하여 다른 사이트에 액세스할 수 있습니다. 대부분의 사람들이 웹상에서 은행 업무, 증권 거래 등을 수행한다는 점을 감안할 때 이것은 매우 심각한 일입니다.
  실제로 해야 할 작업은 방문하는 각각의 모든 인터넷 사이트에 대해 고유한 암호를 사용하는 것입니다. 이 암호는 사이트에서 허용하는 최대 길이로 복잡하고 무작위로 생성되어야 이상적입니다. 물론 도구를 사용하지 않고 복잡한 암호를 무작위로 생성할 수 있는 사람은 거의 없을 것입니다. 하지만 도움이 될 수 있는 많은 도구가 존재하므로 이에 대해서는 걱정할 필요는 없습니다. 당연한 말이겠지만 정말로 신뢰할 수 있는 출처에서 제공된 도구를 사용해야 할 것입니다.
  이 칼럼에서는 이러한 문제를 해결하기 위해 필자가 작성한 Password Minder라는 도구에 대해 설명합니다. 이 도구를 실제로 사용하지는 않더라도 그 구현 방법을 알아두면 유용할 것입니다.

Internet Explorer 및 암호
  Microsoft Internet Explorer는 암호를 기억하는 기능을 기본적으로 지원합니다. 그런데 Microsoft를 비롯한 대부분의 기업에서 직원들에게 이 기능을 사용하지 않도록 권장하는 이유는 무엇일까요? 먼저 이 기능이 구현되는 방법에 대해 생각해 보겠습니다. 브라우저가 암호 필드를 자동으로 채우기 전에 어떠한 암호도 물어보지 않는다면 사용자의 로그인 자격 증명(사용자의 Windows 암호)을 사용하여 기억하고 있는 암호에 대한 암호화 키를 만들기 때문일 것입니다. 사용자의 로그인 자격 증명을 암호화 키의 소스로 사용하여 데이터를 암호화하는 것을 매우 간단하게 만들어 주는 한 쌍의 Win32 API(CryptProtectData 및 CryptUnprotectData)가 존재합니다. 이 기능은 .NET Framework 2.0에서 ProtectData라는 .NET Framework Library의 새 클래스를 통해 관리되는 응용 프로그램에 제공됩니다.
  그러나 여기서 잠시 생각해 볼 것이 있습니다. 브라우저가 사용자로부터 추가 암호를 요구하지 않고 이러한 암호를 언제든지 해독할 수 있다면 사용자의 로그온 세션에서 실행 중인 시스템의 다른 모든 코드가 동일한 작업을 수행할 수 있습니다. Internet Explorer와 동일한 알고리즘을 사용하여 암호를 해독한 다음 공격자가 선택한 FTP 사이트에 이러한 암호를 업로드하는 바이러스를 가정해 봅니다. 전자 메일의 악의적인 첨부 파일을 열어 바이러스 코드를 부주의하게 실행하면 Internet Explorer가 관리하는 모든 암호가 유출될 것입니다. 바이러스는 브라우저만큼이나 간단하게 CryptUnprotectData를 호출할 수 있습니다. 솔직히 말해서, 더 성공적인 바이러스 중 일부(예: Nimda)가 이것을 수행하지 않았다는 사실에 놀란 적이 있습니다. 분명한 것은 이 기능이 널리 사용되기 때문에 공격 대상이 될 가능성이 많다는 점입니다. 유해한 전자 메일 첨부 파일을 열었을 때 이와 같은 공격에 노출될 수 있다는 점을 감안한다면 브라우저에서 암호를 관리하도록 결정하는 것을 다시 고려해야 할 것입니다.
  브라우저가 관리하는 암호의 또 다른 문제는 무엇보다도 각 암호를 사용자가 직접 선택한다는 점인데, 일반적으로 사용자가 선택하는 암호는 적절하지 않습니다. 예를 들어, "asdf7890"은 쉽게 입력할 수 있다는 점을 제외하면 바람직하지 않은 암호입니다. 사용자는 암호를 무작위로 선택할 수 있는 적절한 소스를 가져야 합니다. 필자가 본 적이 있는 한 가지 기술은 암호의 각 문자를 결정하기 위해 주사위를 던지는 것입니다. 이것은 괜찮은 방법이지만 대부분의 사람은 매일 이 기술을 사용할 만큼 여유롭지 않을 것입니다. 게다가 암호를 만드는 동안에 직장 상사가 이러한 광경을 목격했을 때 주사위 놀이를 하는 것이 아니라고 설명해야 할 것입니다.

암호 기록
   많은 사람들이 암호를 적어 두는 것을 우습게 여기지만, 이것은 경우에 따라 적절한 방법일 수 있습니다. 암호를 적은 메모지를 모니터에 붙여놓는 부주의한 행동을 하지 않는다면 암호를 기록해 두는 것은 브라우저에서 기억하도록 하는 것보다 훨씬 더 바람직합니다. 암호를 해독하여 공격자에게 제공하는 바이러스가 사용자의 지갑에 있는 메모지를 꺼내서 그 내용을 읽을 수는 없기 때문입니다.
  그러나 암호가 매우 많을 경우 이러한 암호를 모두 적어서 지갑에 보관할 수는 없을 것입니다. 게다가 제대로 만들어진 복잡한 암호를 사용하고 있다면 이러한 암호를 읽어서 입력할 때 실수를 범하기 쉬울 것입니다. 또한 암호를 적어둔 메모지를 넣은 채 세탁을 한다거나 지갑을 도난 또는 분실하는 경우도 생길 수 있습니다.
  필자는 컴퓨터의 파일에 암호를 보관하는 사람을 본 적이 있습니다. 주의를 기울인다면 이것은 그럭저럭 괜찮은 방법이며 클립보드에 암호를 복사하여 사용할 수 있다는 점에서 더 간편합니다. 암호화 파일 시스템을 사용하여 브라우저가 제공하는 것과 동일한 수준의 보안을 실현할 수 있으며 이를 통해 로그인 자격 증명이 포함된 암호 파일을 효과적으로 암호화할 수 있습니다. 그런데 이 방법을 사용하는 친구의 암호 목록을 우연히 본 적이 있는데(친구가 랩톱에서 암호 목록을 열어둔 채로 잠시 자리를 비웠을 때), 이러한 사실을 말해 준 후부터 그 친구는 더 이상 이 방법을 사용하지 않습니다.

더 나은 솔루션: 암호 멀티플렉서
  저는 몇 년 전에 암호 멀티플렉서를 작성하여 고유한 암호 관리 문제를 해결하기로 결정했습니다. 그 당시의 상황은 다음과 같았습니다. 우선 하나의 적절한 마스터 암호만을 기억하고자 했습니다. 마스터 암호는 Windows 로그인 암호와 다르므로 기술적으로 두 개의 강력한 암호를 기억해야 합니다. Windows에 로그인하면 암호를 묻는 메시지가 나타날 때마다 단순히 마스터 암호를 입력하고 시스템에서 이것을 제가 방문하는 사이트의 고유한 암호로 자동으로 변환할 수 있도록 하려고 했습니다. 저의 목표는 방문하는 각 사이트에 대해 무작위로 작성된 고유하고 긴 암호를 가지는 것이지만 실제로 이러한 암호를 보거나 수동으로 입력하기를 원하지는 않았습니다. 또한 브라우저 뿐만 아니라 다른 응용 프로그램에서도 이것이 적용될 수 있기를 원했습니다. 예를 들어, 클라이언트의 네트워크에 VPN 연결을 설정할 때 암호 멀티플렉서를 사용하고자 했습니다.
  그렇다면 암호 멀티플렉서를 사용하는 것과 브라우저가 암호를 기억하는 것의 차이점은 무엇입니까? 단일 마스터 암호에서 파생된 키를 사용하여 실제 암호 모음을 암호화한다고 가정했을 때, 멀티플렉서에서는 실제 암호 중 하나를 검색하려고 할 때마다 마스터 암호를 입력해야 합니다. Windows 로그인 자격 증명을 사용하여 암호를 암호화하지 않기 때문에 시스템에 몰래 들어온 악의적인 소프트웨어에서 암호를 자동으로 사용할 수 없습니다. 물론 이 방법이 완벽하지는 않습니다. 예를 들어, 시스템의 루트 손상을 통해 공격자는 모든 키 입력을 읽는 키보드 드라이버를 설치할 수 있습니다. 하지만 브라우저가 암호를 기억하는 방법보다 훨씬 더 안전합니다.
  솔직히 말해서 저는 이러한 모든 요구 사항을 충족하는 암호 멀티플렉서를 작성하는 방법을 몰랐지만 원래 언급했던 목표보다 약간의 추가 키 입력만 있으면 된다는 것이 최종 디자인에서 밝혀졌습니다. 저는 지금까지 수년 동안 이 도구를 사용하고 있으며 실제로 만족하는 편입니다.
  최종 디자인을 결정하기 전, 간단히 마스터 암호로부터 직접 각 사이트의 암호를 파생하는 방법을 고려했습니다. 예를 들어, 단순히 각 사이트에 대해 무작위로 생성된 비트 집합인 솔트 값을 저장합니다. 그런 다음 마스터 암호와 함께 이 솔트를 해싱하여 사이트에 대한 암호 자료를 얻을 수 있습니다. 이것은 멀티플렉서 구현을 매우 간단하게 만들지만 마스터 암호를 변경하는 것이 다소 어려워집니다. 저의 경우에는 현재 약 50개 정도의 암호를 관리하고 있는데 모든 사이트에서 암호를 동시에 변경해야 합니다.
  이 솔루션의 또 다른 문제는 많은 사이트에서 허용되는 암호에 대해 제한을 둔다는 점입니다. 예를 들어, 많은 사이트에서 문장 부호를 암호로 사용하는 것을 허용하지 않습니다. 또한 더 많은 사이트에서는 암호 길이를 제한합니다. 저는 6자보다 긴 암호를 허용하지 않는 사이트를 여러 번 본 적이 있습니다. 심지어 이러한 제한에 대해 설명조차 제공하지 않는 경우가 빈번합니다. 어느 누구도 사용자가 아주 긴 암호를 사용할 것이라고 예상하지 않는 것이 분명합니다. 따라서 암호를 요구하는 웹 사이트를 개발하는 경우 허용할 암호의 유형을 명백하게 해야 합니다. 가능하다면 매우 긴 암호를 허용하는 것이 바람직합니다. 누군가가 100자 길이의 암호를 제공한다고 해서 문제될 것은 없으며 실제로 이런 암호가 제공될 가능성도 거의 없으므로 더 적절한 보안을 원하는 사용자를 위해서 긴 암호를 허용해야 합니다.
   마지막으로 저는 가끔씩 사용하는 몇 개의 스마트 카드를 갖고 있는데 이러한 스마트 카드는 4자 길이의 PIN 코드가 필요합니다. 이러한 모든 문제를 고려했을 때 단일 마스터 키에서 암호를 직접 생성할 수 없다는 것을 금방 알 수 있었습니다. 그러나 이것은 흥미로운 방법이었습니다. 또한 누군가가 파생된 암호의 대규모 샘플을 액세스할 수 있는 경우 마스터 암호를 추측할 수 있으므로, 암호화 측면에서 최상의 방법은 아니었습니다.

Password Minder
   제가 최종적으로 작성한 것은 Password Minder라는 도구입니다. 이 도구의 이름을 Password Multiplexer라고 지어야 했지만 기술 지식이 부족한 사용자는 이러한 이름이 낯설게 느껴질 것입니다. 가능한 모든 암호 편집 필드를 자동으로 후크(hook)할 수 있도록 소프트웨어를 운영 체제와 통합하는 안전한 방법이 없었기 때문에 아주 간단한 방법을 선택했습니다. 즉, 바탕 화면에서 바로 가기를 만들고 바로 가기의 속성 시트를 통해 "바로 가기 키" 설정을 구성함으로써 Password Minder를 바로 가기 키 조합에 포함시켰습니다. 웹 양식 또는 대화 상자의 암호 필드에 있을 때마다 바로 가기 키 조합(Control-Shift-P)을 누르면 마스터 암호를 묻는 작은 프롬프트가 표시됩니다(그림 1의 대화 상자 참조).


그림 1 마스터 암호 프롬프트

  암호를 입력하면 시스템은 마스터 키를 얻기 위해 약간의 계산을 수행합니다. 이러한 계산의 유발 및 구조에 대해서는 나중에 자세히 설명하겠습니다. 몇 초가 지나면 Password Minder가 암호를 관리하기 있는 웹 사이트 및 응용 프로그램 목록을 보여 주는 또 다른 양식이 나타납니다. 대부분의 사이트는 전자 메일 주소를 사용자 이름으로 사용하지만 은행과 같은 사이트에서는 다른 이름이 필요하므로, 이처럼 좀더 까다로운 사이트에서 사용되는 사용자 이름을 이 목록을 통해 한 눈에 볼 수 있습니다. 그림 2에는 저의 암호 목록이 나와 있습니다. (제가 선택한 사용자 이름은 비워 두었습니다.) 그림에 표시된 스크롤 막대를 통해, 관리해야 하는 암호가 아주 많다는 것을 유추할 수 있습니다. 각 암호는 무작위로 작성된 고유한 암호여야 하고 사이트 또는 응용 프로그램에서 허용하는 만큼 강력해야 합니다.


그림 2 암호 목록

  키보드에서 손을 뗄 필요 없이, 사이트 이름의 첫 글자를 누르면 목록이 자동으로 스크롤되므로 원하는 암호를 신속하게 찾을 수 있고 Enter 키를 눌러 해당 암호를 선택할 수 있습니다. 그런 다음 Password Minder는 마스터 키를 사용하여 해당 암호만을 해독하고 입력 대기열에 키 입력 메시지를 삽입하여 암호를 자동으로 입력합니다. 마스터 키가 노출될 가능성을 줄이기 위해 Password Minder는 즉시 종료됩니다. 일반적으로 Password Minder는 몇 초 동안만 사용되기 때문에 마스터 키는 하루 중 아주 짧은 시간 동안만 메모리에 제공됩니다.
  실제로 Password Minder가 관리되는 응용 프로그램이기 때문에 사용이 끝난 마스터 키가 메모리에서 삭제되도록 하는 것은 매우 어렵습니다. 이것은 가비지 수집을 사용하는 모든 언어(예: .NET 및 Java)에 있어 매우 큰 문제입니다(.NET Framework 2.0에서는 새 SecureString 클래스로 인해 이 작업이 더 간단해짐). 바로 이러한 이유 때문에 최소한 기본적으로는 암호를 입력한 후 즉시 종료하도록 Password Minder를 디자인했습니다. 그런 다음에는 운영 체제의 기능, 즉 Password Minder가 방금 비운 동일한 메모리를 사용하는 종료한 다른 모든 프로세스가 새 프로세스에 매핑되기 전에 메모리가 완전히 비워지도록 하는 기능에 의존할 수 있습니다. 이 방법은 완벽하진 않지만(경우에 따라 마스터 키가 스왑 파일에 포함될 수 있음), 제 경우에는 충분했습니다. 만약 컴퓨터가 손상되어 스왑 파일이 빼앗길 위험이 상당히 큰 상황에서, 또한 키 입력이 모니터링되고 있는 경우라면 공격자가 어떤 식으로든 마스터 암호를 이미 보유하고 있다는 것을 뜻합니다.
  이상하게 들리겠지만 운영 환경에 포함되지 않는 암호 관리 도구를 사용하는 것이 제게는 유리합니다. Windows를 소유하는 모든 사람이 이 도구를 사용하지는 않는다는 사실은 공격자의 대상이 될 가능성이 그만큼 줄어든다는 것을 의미합니다. 몰론 제가 이러한 사실에 의존하는 것은 아닙니다. 뒤에서 간단하게 다루겠지만, Password Minder는 보안을 매우 심각하게 간주합니다. 공격자가 암호 파일을 획득한 경우에도 강력한 마스터 암호와 암호 스트레칭 기술이 사용되기 때문에 암호 파일에 대한 오프라인 암호 추측(brute-force) 또는 딕셔너리 공격은 결국 실패할 것입니다.

마스터 암호에서 마스터 키로
   Password Minder는 그림 1의 대화 상자에서 마스터 암호를 얻으면 암호 파일의 마스터 키를 파악하기 위한 약간의 퍼즐을 풀어야 합니다. 암호 스트레칭이라고 부르는 이 기술은 아무리 경험이 풍부한 공격자라도 암호 추측(brute-force) 공격을 통해 암호를 검색할 수 없도록 적절한 암호를 가져와 강력하게 만듭니다. Password Minder가 사용하는 기술은 암호 기반 암호화를 위한 PKCS(Public Key Cryptography Standards)에 설명되어 있습니다. 전문적으로 PBKDF2(Password Based Key Derivation Function 2)라고 부르는 이 기술은 마스터 암호 및 솔트 값으로 시드되는 암호화 의사 난수 생성기를 반복 실행하는 방법으로 작동합니다. 이 의사 난수 생성기의 중심에는 해시 알고리즘이 있습니다. 원하는 모든 해시 알고리즘을 사용할 수 있는데 저는 널리 알려진 암호화 전문가인 Niels Ferguson 및 Bruce Schneier의 Practical Cryptography(John Wiley & Sons, 2003)에서 제공되는 권장 사항에 따라 256비트 버전의 보안 해시 알고리즘(SHA-256)을 선택했습니다.
  저는 현재 18비트의 보안을 암호에 효과적으로 추가하는 이 알고리즘의 2¹⁸ 반복을 사용하고 있습니다. 공격자는 암호 파일의 복사본을 어떤 식으로든 얻을 경우 모든 가능한 암호를 시도하고 마스터 키를 계산한 다음 목록의 암호 중 하나를 해독함으로써 마스터 키에 대한 암호 추측(brute-force) 공격을 수행할 수 있습니다. 결과적으로 공격자는 마스터 암호를 추측할 수 있는데 이것은 암호 해독이 UTF-8 인코딩으로 암호를 나타내는 일반 텍스트 바이트 스트림이 되고 특정 문자만 암호에 존재하기 때문입니다. 그런 다음 공격자는 마스터 키를 사용하여 다른 암호를 동일한 방식으로 해독하고 암호의 유효한 UTF-8 인코딩을 갖고 있는지 확인하여 자신이 올바른 암호를 발견했다는 사실을 더 확실하게 알 수 있습니다.
   그렇다면 공격자를 올바른 암호를 발견할 때까지 몇 번의 시도를 해야 합니까? 이번 달에 제가 사용하고 있는 마스터 암호는 12자이고 사전에 있는 단어를 포함하지 않으며 대문자, 소문자, 숫자 및 문장 부호로 되어 있습니다. 이는 영어 키보드에 있는 문장 부호 문자의 개수를 고려할 때 26+26+10+32=94개의 문자에서 선택할 수 있음을 의미합니다. 따라서 제 암호는 94¹²개의 가능한 암호 집합(거의 2⁷⁹에 근접함)에서 선택되며 79비트 키는 매우 강력합니다. 그러나 실제로는 가능한 모든 문자, 숫자 및 문장 부호 문자를 균일한 분포로 사용하지 않으므로 진정한 79비트의 강력한 보안을 구현할 수 없으며 바로 이러한 점에서 문제가 발생합니다.
  SHA-256에 기초하여 의사 난수 생성기의 2¹⁸ 반복을 수행하도록 공격자에게 강제함으로써 암호 추측(brute-force) 공격에서 공격자가 수행해야 하는 작업이 크게 증가합니다. 각 암호 추측에 대해 공격자는 2¹⁸개의 추가 단계를 수행해야 합니다. 따라서 이것은 암호 강도를 18비트 늘리는 것으로 생각할 수 있습니다. 따라서 암호 추측(brute-force) 공격은 암호를 찾기 위해 2⁷⁹ 단계가 아니라 2⁹⁷ 단계를 수행합니다. 이제 앞서 언급한 것처럼 마스터 암호에는 2⁷⁹ 비트의 엔트로피가 더 이상 존재하지 않습니다. 실제로는 선택한 모든 암호를 이러한 스트레칭을 사용하여 강화할 수 있습니다. 강력한 암호를 PBKDF2와 같은 스트레칭 기술과 결합하면 암호 파일의 복사본을 획득한 사람들로부터 보호하기 위한 강력한 수단이 제공됩니다. 이것은 특히 암호 파일의 이동이 잦은 경우에 중요합니다(흔히 암호 파일을 가지고 다니거나 쉽게 액세스할 수 있도록 네트워크 공유에 게시하기 때문에).

올바른 마스터 암호 선택
  Password Minder는 또한 사용자가 암호를 제공할 때마다 엔트로피 측정을 제공합니다. 예를 들어, 새 마스터 암호를 입력하면 Password Minder는 사용 중인 문자 유형과 암호 길이를 검사하여 암호가 가질 수 있는 최대 엔트로피를 표시합니다. Password Minder는 마스터 암호의 경우 60비트 엔트로피보다 작은 것을 허용하지 않습니다. 물론 P@ssw0rd!!와 같이 66비트의 최대 엔트로피 값으로 등록되는(프로그램이 검사하는 모든 범주의 문자를 사용하므로) 적합하지 않은 마스터 암호를 사용하는 것이 불가능하지는 않습니다.
  기억할 수 있는 긴 마스터 암호를 선택하려면 어떤 사진 한 장을 상상하여 짤막한 이야기를 만듭니다. 이렇게 하면 "Dark leaves fall to the ground as the Autumn wind howls around my house"라는 긴 문장을 DlfttgatAwhamh로 축약하여 암호로 사용할 수 있습니다. 이 암호를 조금 더 보완하기 위해 @#32를 삽입한다면 최종 결과는 Dlfttg@#32atAwhamh가 됩니다. 이것은 아주 쉬운 일입니다. 심지어 저는 사무실에서 처음 며칠 동안 사진을 붙이고 있는 와중에도 새로운 암호를 외우고 있었던 적이 있습니다. 다른 사람들은 사진을 보면 추억을 떠오를지 몰라도 저 같은 경우에는 수많은 암호들이 연상됩니다.

심층적 방어
  긴 마스터 암호와 암호 스트레칭이 결합되어 강력한 보안을 제공하지만 모든 사람이 볼 수 있도록 암호 파일을 웹 사이트에 게시하지는 않을 것입니다. 암호 파일을 신중하게 보호하기 위해서 계층화된 방어를 구축하는 것이 중요합니다. Password Minder는 암호 파일을 사용자 프로필에 저장합니다. 사용자 프로필에서 디렉터리에 대한 기본 액세스 제어는 사용자 자신이나 관리자만 저장된 파일을 보는 것을 허용합니다. (단, 회사에서 "로밍 프로필"을 설정한 경우 이 데이터는 사용자가 로그인하는 시스템 간에 로밍되며 도중에 캡처될 수 있습니다.) 암호 파일을 다른 곳에 저장하는 경우 Password Minder는 사용될 때마다 액세스 제어 목록을 동일한 방법으로 수동으로 설정합니다(파일을 읽고 쓸 수 있는 권한을 사용자 자신과 관리자에게만 허용). 물론 휴대하는 USB 메모리 스틱과 같은 FAT 파티션에 보관하는 암호 파일의 경우에 Password Minder는 이 단계를 건너뜁니다. 파일 액세스를 제한하고 강력한 마스터 암호를 권장하며 이러한 암호를 사용하기 전에 스트레칭함으로써 Password Minder는 심층적 방어를 제공합니다.

스트레칭 추가 정보
   암호 스트레칭에는 시간이 소요되고 컴퓨터 속도가 제각각 다르기 때문에 Password Minder에서는 스트레칭 도중에 수행하는 반복 횟수를 구성할 수 있습니다. 마스터 암호를 재설정할 때마다 이 값을 변경할 수 있으며 Password Minder는 90일마다 변경을 수행하라는 알림을 보냅니다. 이 값을 변경하려는 경우 처음 실행 시에 Password Minder는 암호 파일 설정을 안내하는 마법사를 제공합니다. 이 마법사를 사용하면 컴퓨터 속도를 테스트하여 적절한 스트레칭 수준을 파악할 수 있습니다(그림 3참조).


그림 3 컴퓨터 속도 테스트

   슬라이더 막대의 각 눈금은 스트레칭의 추가 비트를 나타냅니다. 현재 구현은 슬라이더 막대에서 가장 낮은 설정인 최소 216의 반복을 허용합니다. 제가 1년 정도 사용한 랩톱에서는 이것을 계산하는 데 1초가 걸립니다. 가장 높은 슬라이더 설정은 2²⁵이며 저의 경우 솔직히 이 작업이 완료되는 것을 기다려 본 적은 없습니다. 그러나 무어의 법칙에 따라 컴퓨터의 속도가 점점 더 빨라지므로 언젠가는 가장 높은 설정도 가능할 것입니다.

결론
  다음 번에는 PBKDF2 알고리즘을 구현하는 클래스를 비롯한 Password Minder의 핵심적인 내용을 살펴보고, 이 프로그램이 마스터 키에서 파생된 고유 키를 사용하여 사용자 이름과 암호를 암호화하는 방법에 대해 설명할 계획입니다. 이 문서의 맨 위에 있는 링크를 사용하면 Password Minder의 바이너리 및 사용 지침과 함께 주로 C#로 되어 있는 코드를 다운로드할 수 있습니다. 현재 버전은 .NET Framework 1.1로 작성되었으므로 Password Minder를 실행하려면 .NET Framework 1.1이 필요합니다.
  .NET Framework가 없는 경우에는 http://www.schneier.com/passsafe.html 에서 제공되는 Bruce Schneier의 Password Safe 프로그램을 사용하는 것을 고려합니다. 중요한 사실은 신뢰할 수 있는 암호 관리 도구를 선택하여 항상 사용하는 것입니다. 또한 방문하는 모든 사이트에서 사용하는 암호가 서로 달라야 합니다.

질문이나 의견이 있으시면 Keith  briefs@microsoft.com에게 보내 주십시오.