OpenVPN 로그인에서 정적 챌린지 코드가 가는 자리

클라이언트는 비밀번호 입력란 뒤에 두 번째 상자를 표시하고, 하드웨어 토큰의 코드를 입력해도 로그인은 인증 오류로 계속 실패합니다. 그 상자가 존재한다는 것은 프로필이 그것을 요청했다는 뜻입니다. 서버가 값을 이해하는 형식으로 받았는지는 다른 문제이며, 먼저 답할 가치가 있는 것은 바로 그쪽입니다.

클라이언트가 실제로 표시하는 프롬프트에서 시작하십시오

프로필은 프롬프트 문자열과 입력하는 동안 응답을 표시할지 제어하는 플래그를 갖는 정적 챌린지 지시문을 담을 수 있습니다. 프롬프트는 대화 상자에서 보이는 문구이고, 플래그는 같은 입력에 대한 표시 설정입니다. 둘 다 서버에 무엇을 어떻게 검증하라고 알려 주지 않습니다.

실제로 주어진 입력란을 세어 보십시오. 사용자 이름용 입력란 하나와 가려진 입력란 하나는 챌린지가 전혀 없는 평범한 비밀번호 로그인입니다. 비밀번호 뒤에 자체 레이블을 달고 나타나는 두 번째 입력란은 클라이언트가 챌린지 상호작용을 구현한 것입니다.

사용하는 클라이언트에 두 번째 상자가 전혀 나타나지 않는다면, 그 클라이언트가 상호작용을 구현하지 않았거나 관리 인터페이스 같은 다른 프런트 엔드를 통해서만 구현했을 수 있습니다. 클라이언트를 확인하는 편이 프로필을 다시 쓰는 것보다 저렴하며, 불일치는 대개 바로 거기에 있습니다.

서버가 이미 지원해야 하는 것

프로필은 클라이언트가 무엇을 수집해야 하는지 설명할 뿐입니다. 서버의 검증을 켜지 않으며, 해당 인증 통합이 없는 서버는 단지 알아보지 못하는 비밀번호를 받게 됩니다. 그래서 일부 배포에서는 프롬프트를 표시하고 모든 코드를 거부하며, 어떤 메커니즘이 검사를 수행하는지에 대한 운영자의 답변이 중요한 이유이기도 합니다.

어떤 메커니즘이 검사를 수행하는지 운영자에게 물어보십시오. PAM과 대화하는 플러그인일 수도 있고, 응답을 토큰 서비스에 대해 검증하는 스크립트 후크일 수도 있으며, 묶인 값을 스스로 분석하는 관리 기반 통합일 수도 있습니다. 각각은 조금씩 다른 입력을 기대합니다.

여기서 기대치도 조정해야 합니다. 두 번째 프롬프트는 입력 메커니즘이지, 두 번째 요소가 강제된다는 증거가 아니며, 강제는 서버 쪽에서 일어나고 잘못된 코드를 시험할 때만 드러납니다.

관리 인터페이스가 보내는 인코딩된 필드

프런트 엔드가 관리 인터페이스를 통해 연결을 구동할 때, 비밀번호와 챌린지 응답은 제출 전에 하나의 값으로 묶입니다. 관리 인터페이스 참조에는 접두사 뒤에 비밀번호와 응답을 별도의 Base64 구성 요소로 두는 형식이 문서화되어 있습니다.

Base64는 인코딩이지 보호가 아닙니다. 그 필드를 읽을 수 있는 누구에게도 무엇을 숨기지 않으며, 일회용 코드를 재사용 가능한 무엇으로 바꾸지도 않습니다. 묶인 값은 비밀번호와 같은 취급을 받아야 합니다: 공유 프로필에서도, 명령 줄에서도, 진단 로그에서도 빼십시오.

그 인코딩은 가장 흔한 혼동의 원인이기도 한데, 비슷해 보이지만 호환되지 않는 세 가지 형태가 있기 때문입니다. 순수한 자격 증명 파일은 비밀번호를 담습니다. 비밀번호와 코드를 그대로 이어 붙인 것은 다른 문자열을 담습니다. 관리 클라이언트의 묶인 응답은 세 번째를 담습니다. 오류가 사라졌다는 이유만으로 필드를 바꾸기 전에 검증 경로가 어느 것을 기대하는지 확인하십시오.

정적과 동적: 서로 다른 시점

정적 챌린지는 첫 자격 증명을 제출하기 전에 알려지므로 클라이언트가 미리 물을 수 있습니다. 동적 챌린지는 더 늦게 도착하며, 교환이 이미 시작된 뒤 인증 워크플로가 보내고, 대화 중간의 요청을 처리할 수 있는 클라이언트가 필요합니다.

하나에 대한 지원이 다른 하나를 주지는 않습니다. 정적 프롬프트를 구성하는 프로필 지시문은 서버가 시작한 챌린지를 구현하지 않으며, 동적 요청을 처리하는 프런트 엔드도 정적 프롬프트를 표시하지 못할 수 있습니다. 어느 쪽이 요청을 시작했는지 읽는 것이 둘을 구분하는 가장 빠른 방법입니다.

무인 운영은 이것이 화면 문제가 아니라 설계 문제가 되는 지점입니다. 저장된 코드는 부팅 시점의 지속적인 자격 증명이 아니며, 몇 시간 뒤의 재연결에는 새 입력이 필요하며, 배포가 운영자가 의도적으로 활성화한 토큰 방식을 지원하는 경우는 예외입니다.

성공과 실패를 모두 시험하십시오, 대화 상자만이 아니라

시험의 두 절반을 모두 실행하십시오. 올바른 자격 증명과 유효한 응답은 성공해야 하고, 올바른 자격 증명과 일부러 틀린 응답은 거부되어야 합니다. 둘 다 성공한다면 클라이언트가 아무것도 검증하지 않는 입력을 모으고 있는 것이며, 대화 상자를 제어 장치로 착각한 것입니다. 그 한 번의 시험이 어떤 프로필 검토보다도 많은 배포를 잡아냅니다.

그다음 재연결 후의 연결을, 등록되지 않은 계정으로, 그리고 사용자가 실제로 실행하는 클라이언트를 통해 반복하십시오. 프롬프트가 나타나는 것은 클라이언트의 동작이고, 잘못된 코드가 거부되는 것은 서버가 무언가를 강제하고 있다는 뜻입니다.