유효한 일회용 코드가 VPN 로그인에서 실패하는 이유

VPN 클라이언트를 열고 비밀번호를 입력한 뒤 인증 앱의 여섯 자리를 넣으면 유효하지 않다고 돌아옵니다. 두 번, 그리고 세 번째도. 계정은 어제부터 바뀐 것이 없으므로 인증 앱의 항목을 삭제하고 다시 스캔하고 싶어지지만, 대개 그것은 잘못된 수리입니다. 일회용 코드는 두 번째 비밀번호가 아닙니다. 게이트웨이는 특정 단계에서, 특정 등록 항목으로부터, 특정 시간 창 안에서 그것을 요구해야 하며, 대부분의 거부는 숫자가 비교되기 전에 일어납니다. 등록을 건드리기 전에 자신이 어느 단계에 있는지 파악하십시오.

프롬프트 순서가 어느 흐름에 있는지 알려준다

코드가 관련된 VPN 로그인은 거의 세 가지 형태로 나뉩니다. 두 단계 형태에서는 클라이언트가 비밀번호를 보내고, 서버가 챌린지를 발급하며, 클라이언트가 다시 묻습니다. 결합 형태에서는 게이트웨이가 비밀번호와 코드를 한 번의 제출로 요구합니다. 이어 붙이는 경우도 있고, 운영자만 문서화한 구분자 뒤에 넣는 경우도 있습니다. 브라우저 형태에서는 클라이언트에 입력란이 아예 없습니다. 코드는 웹 페이지로 들어가거나 푸시 승인이 이를 대신하며, 데스크톱 클라이언트는 결과를 기다립니다.

형태를 잘못 잡으면 나쁜 코드처럼 보입니다. 비밀번호 전용 입력란에 새 코드를 붙여 넣으면 서버는 그것을 비밀번호의 일부로 읽습니다. 클라이언트 쪽에서는 OpenVPN 2.4 이후 버전이 차이를 드러냅니다. AUTH_FAILED,CRV1: 로 응답하는 서버는 챌린지 응답을 기대하므로 프로필에 static-challenge 또는 SCRV1: 형식의 비밀번호 파일이 필요합니다. auth-user-pass 만 가진 오래된 프로필은 비밀번호를 인증한 뒤 멈추며, 로그에서는 OTP 실패처럼 보이지만 코드는 전혀 전송되지 않았습니다.

WireGuard는 예외로 언급할 만합니다. 사람이 아니라 키 쌍을 인증하므로 코드를 위한 입력란이 없습니다. 공급자가 그런 것을 광고한다면 터널 밖의 무언가가 그것을 받아들이는 것입니다.

서버는 여섯 자리로 무엇을 하는가

시간 기반 코드는 RFC 6238 을 따르며, 이는 RFC 4226의 오래된 카운터 기반 구성을 감싼 것입니다. 움직이는 요소에 대한 HMAC을 기본적으로 여섯 자리로 자릅니다. TOTP에서 움직이는 요소는 현재 Unix 시간을 단계로 나눈 값이며, 운영자가 바꾸지 않았다면 30초입니다. 검증자는 여러분의 숫자를 저장된 값과 비교하지 않습니다. 공유 시드에서 기대 코드를 다시 계산하며 보통 이웃 단계도 받아들이므로, 느린 왕복 때문에 로그인이 실패하지는 않습니다.

놓치기 쉬운 결과가 둘 있습니다. 휴대폰의 시간대는 무관합니다. 시드는 로컬 시계를 결코 보지 않으며 실제 UTC와의 차이만 중요합니다. 두어 분 앞선 기기는 깔끔한 카운트다운을 보여주면서도 모든 코드에서 실패합니다. 그리고 코드는 설계상 일회용입니다. 검증자는 그 시드에 대해 마지막으로 받아들인 카운터 값을 기억하므로, 같은 숫자를 다시 제출하면 같은 창 안에서도 거부됩니다. 시간 초과 후 재시도하는 클라이언트는 방금 보낸 코드를 태워 버릴 수 있습니다.

카운터 기반 토큰은 누를 때마다 카운터를 움직이므로, 코드가 생성되었지만 전송되지 않은 채로 남으면 동기에서 벗어납니다. 일반적인 수리는 앞쪽 몇 개 값을 받아들이는 재동기화 창입니다. 운영자가 HOTP를 등록했는데 앱이 TOTP를 표시하면 모든 값이 시계 문제처럼 보이는 방식으로 틀립니다. QR 코드 뒤의 프로비저닝 URI는 유형, 자릿수, 주기, 해시를 알려줍니다.

잘못된 코드처럼 보이는 실패

가장 흔한 원인은 등록된 항목입니다. 인증 앱은 발급자와 계정으로 항목에 라벨을 붙이므로, 같은 VPN에 두 개의 신원을 가진 사람은 라벨이 한 글자만 다른 두 항목을 갖게 될 수 있습니다. 코드는 그것을 생성한 시드에만 유효하고 다른 무엇에도 유효하지 않습니다. 휴대폰의 라벨은 서버가 기록한 사용자 이름과 비교하십시오. 자신이 입력했다고 기억하는 것과 비교하지 마십시오.

두 번째는 맞지 않는 매개변수 집합입니다. 여덟 자리, 60초 주기 또는 SHA-256으로 등록된 시드는 여섯 자리, 30초, SHA-1을 기대하는 검증자가 거부하는 코드를 만들며, 클라이언트에서는 그것을 잘못된 코드와 구별할 수 없습니다. 이것은 QR 코드 사진에서 항목을 다시 추가한 이전 작업이나 토큰 기록을 기본값으로 재구성한 뒤에 나타납니다.

세 번째는 코드 문제가 아닙니다. 게이트웨이는 보통 잘못된 비밀번호, 만료된 코드, 비활성화된 계정에 대해 하나의 일반적인 인증 실패를 의도적으로 반환하여, 누구도 어느 요소가 실패했는지 탐색할 수 없게 합니다. 클라이언트 배너 대신 게이트웨이나 RADIUS 로그를 읽으십시오. 발급되지 않은 챌린지, OTP 속성이 없는 접근 거부, 정책 거부는 화면에서는 똑같이 보이지만 다음 단계는 다릅니다.

범위를 좁히는 짧은 절차

가장 저렴한 확인부터 시작하고 성립하지 않는 첫 단계에서 멈추십시오.

1. 새 코드를 기다렸다가 한 번 제출하고, 챌린지가 비밀번호 수락 전에 나타나는지 후에 나타나는지 기록하십시오.
2. 인증 앱의 라벨을 서버가 저장한 사용자 이름과 맞추십시오.
3. 프로필이 챌린지에 응답할 수 있는지 확인하십시오. 위의 CRV1 경우처럼.
4. 기기 시계를 알려진 시간 원본과 비교하십시오. 수십 초를 넘는 차이는 그 자체로 TOTP를 깨뜨립니다.
5. 토큰이 TOTP인지 HOTP인지, 어떤 자릿수와 주기, 해시로 등록되었는지 운영자에게 물으십시오.

상황을 악화시키지 않는 두 가지 규칙이 있습니다. 여러 번 재시도하지 마십시오. 많은 게이트웨이는 계정별로 실패를 세고 잠그거나 응답을 지연시키기 시작하므로, 연타는 작은 설정 오류를 지원 티켓으로 바꿉니다. 그리고 진단 목적으로 토큰을 다시 등록하지 마십시오. 오래된 시드가 무효가 됩니다. 실제 문제가 클라이언트가 보내지 않은 챌린지였다면, 이제 변경 사항이 하나가 아니라 둘이 되어 설명하기 어려워집니다.

시드와 복구 코드를 고리 밖에 두십시오

여섯 자리와 그 뒤의 비밀은 서로 바꿀 수 없습니다. 프로비저닝 QR 코드나 Base32 시드는 계정의 모든 미래 코드를 생성하므로 비밀번호와 같은 범주에 속합니다. 스크린샷에 남기지 말고, 티켓 댓글에 쓰지 말고, 먼저 연락해 온 사람과의 채팅에도 두지 마십시오. 복구 코드는 별도의 메커니즘입니다. 일회용이며 코드 프롬프트를 완전히 건너뛰는 경우가 많고, 계정을 테스트하려고 하나를 쓰면 나중에 필요할 수 있는 대체 수단을 없애게 됩니다.

코드가 있다고 해서 로그인 페이지를 신뢰할 수 있는 것도 아닙니다. 비슷한 도메인의 OTP 프롬프트는 유효한 코드를 모아 시간 창 안에서 다시 재생하며, 어디에 입력하고 있는지는 여전히 인증서가 알려줍니다.

절차가 챌린지에 응답할 수 없는 프로필에 도달하면 프로필을 고치고 새 코드 하나로 다시 테스트하십시오. 맞지 않는 등록 매개변수에 도달하면 누군가 무엇인가를 스캔하기 전에 운영자에게 토큰 기록을 읽어 달라고 요청하십시오. 잠금에 도달하면 클라이언트를 바꾸는 대신 해제될 때까지 기다리십시오. 막고 있는 것은 앱이 아니라 계정 상태입니다.