VPN 비밀번호의 프라이버시는 검증자만큼만 보장된다

VPN 로그인에 대해 네 가지 질문을 차례로 따져 보십시오. 전송 중에 비밀번호를 보호하는 것은 무엇인지, 어느 구성 요소가 그것을 받는지, 그 구성 요소가 그것으로 무엇을 하는지, 그리고 나중에 무엇이 저장되는지. 각각의 답은 서로 다른 통제이며, 하나에 대한 강한 답은 나머지에 대해 아무것도 말하지 않습니다. 실수는 터널 암호화가 네 가지를 모두 덮는 것처럼 다루는 것입니다. 그것은 첫 번째만 덮습니다.

세션이 암호화되었는지가 아니라 누가 세션을 종료하는지 물으십시오.

정확히 누구로부터 암호화되는가?

TLS는 클라이언트와 연결을 종료하는 쪽 사이에서 비밀번호를 보호합니다. 그 종단이 VPN 게이트웨이라면 게이트웨이의 인증 코드가 평문 비밀번호를 보고 검증한 뒤, 그것 또는 파생 값을 다음으로 넘깁니다. 이는 의도된 설계이며 유출이 아닙니다. 경로상의 네트워크 관찰자는 유용한 것을 배우지 못하고, 검증을 수행하는 구성 요소는 필요한 모든 것을 알게 됩니다.

OpenVPN 커뮤니티는 이를 명시적으로 문서화합니다. auth-user-pass-verify는 제출된 자격 증명을 검증 스크립트나 플러그인에 넘깁니다. 이는 구성 요소 간의 의도적인 인계이며, 이름이 붙은 당사자로서 신뢰 모델에 속합니다.

검증자는 비밀번호를 본다

구성 요소가 검증을 위해 비밀번호를 받으면, 비밀이 내부에 머무는지는 그 구성 요소의 접근 통제, 로깅, 코드 품질이 결정합니다. 자격 증명을 로그에 기록하는 스크립트나 그것을 캐시하는 플러그인은 프로토콜이 만든 것보다 훨씬 큰 노출을 만듭니다. 접근은 터널이 아니라 아키텍처와 역할에 달려 있으므로, 검증자를 통제하는 서비스 소유자도 평가에 포함됩니다.

방식이 다르면 노출되는 재료도 다르다. 인증서 인증은 개인 키를 보내지 않고 증명하며, 연합 흐름은 비밀번호를 신원 제공자에게 두고 VPN에 범위가 제한된 어서션을 발급할 수 있습니다. 그런 설계는 범위를 좁히지만, 신뢰하는 모든 당사자를 없애지는 못합니다.

저장된 해시는 다른 단계를 보호한다

NIST 지침은 보호된 전송과 견고한 검증자 저장을 구분합니다. 솔트와 비용이 드는 해시 방식은 저장된 검증자 위협, 즉 데이터베이스가 유출된 뒤에 일어나는 일을 다룹니다. 비교를 위해 입력을 반드시 받아야 하는 런타임 구성 요소에 대해서는 아무것도 하지 않습니다. 지침이 런타임 비밀성을 약속하는 것처럼 읽는 것은 범주 오류입니다.

따라서 잘 해시된 비밀번호 저장소와 노출된 검증 스크립트는 모순 없이 한 제품에 공존할 수 있습니다.

범위를 좁히는 방식을 고르기

게이트웨이가 재사용 가능한 비밀번호를 절대 받지 않아야 한다는 요구라면, 그것을 실제로 보장하는 방식을 고르십시오. 데이터 암호를 바꾼다고 그 속성이 생기지는 않습니다. VPN 서버의 인증서를 검증하면 어느 상대에 도달했는지는 알 수 있지만, 그 상대가 이후 자격 증명을 어떻게 다루는지는 말해 주지 않습니다. 서버 검증을 유지하고, 서비스마다 다른 자격 증명을 사용하며, 조직이 지원하는 신원 흐름을 따르십시오.

비밀번호를 받는 당사자, 그것을 검증하는 당사자, 그리고 어떤 형태로 보관되는지를 기록하십시오. 이 세 가지 답은 연결 프로필 옆에 있어야 합니다. 어떤 특정 터널보다 오래 살아남기 때문입니다.

유용한 질문은 비밀번호가 암호화되었는지가 아니라, 누구로부터 숨겨지는지, 어느 구성 요소가 그것을 받는지, 이후 어떤 형태가 남는지입니다.