패스키는 피싱을 어떻게 막을까? 동기화·복구·세션의 보안 경계

로그인 화면은 비슷하지만 증명하는 방식이 바뀐다

지문을 대거나 얼굴을 보여 주고 로그인이 끝나면, 비밀번호가 생체정보로 교체됐다고 생각하기 쉽다. 패스키의 핵심 변화는 화면보다 뒤쪽에 있다. 서비스에 “서버가 알고 있는 비밀을 나도 안다”고 보여 주는 대신, 등록된 공개키에 대응하는 개인키를 사용할 수 있음을 증명한다.

이 차이는 서버에서 인증정보가 유출되거나 사용자가 가짜 사이트에 접속했을 때 중요해진다. 다만 로그인 방식을 바꿨다고 계정의 모든 진입 경로가 동시에 강해지는 것은 아니다. 잃어버린 기기에서 다시 접속하는 방법, 기존 로그인 세션, 비밀번호로 돌아가는 우회 경로까지 함께 봐야 한다.

이 글은 계정 보안의 구조를 이해하기 위한 분석이다. 특정 서비스의 공격 성공률을 측정하지 않았고, 모든 패스키 구현을 동일한 보안 수준으로 평가하지 않는다. 표준이 정한 인증 관계와 공급자가 제공하는 동기화·복구 정책을 구분해서 읽는다.

개인키·공개키·생체 확인은 서로 다른 역할을 한다

FIDO Alliance의 설명에서 패스키는 비밀번호 없는 공개키 기반 로그인을 위한 수단이다. 생체정보나 기기 잠금 해제는 인증기에 있는 키의 사용을 허용하는 로컬 확인에 쓰일 수 있다. 생체정보를 웹사이트의 새 비밀번호처럼 전송하는 구조가 아니다.

서비스에 패스키를 등록하면 서버에는 공개키와 해당 자격증명을 계정에 연결할 정보가 남는다. 이후 로그인할 때 서버가 보낸 새로운 challenge를 포함한 인증 응답에 서명을 만들고, 서버는 등록된 공개키로 이를 검증한다. 세부 메시지와 검증 절차는 WebAuthn 규격에 정의돼 있다.

요소	맡는 역할	혼동하면 안 되는 것
개인키	로그인 서명을 만드는 핵심 재료	서비스 서버에 보내는 비밀번호가 아님
공개키	서버가 서명을 확인하는 기준	공개키를 알았다고 개인키로 서명할 수 없음
challenge	이번 인증 요청과 응답을 연결	과거 응답을 그대로 다시 쓰는 것과 구분
로컬 PIN·생체 확인	키 사용을 허용할 사용자를 확인	서비스의 모든 권한까지 승인한 것은 아님
로그인 세션	인증 후 요청을 이어 가는 상태	패스키와는 별도로 보호·만료해야 함

공개키가 비밀이 아니라는 사실은 서버의 보안이 중요하지 않다는 뜻이 아니다. 서버가 공격자에게 장악되면 공개키와 계정의 연결을 변조하거나, 인증 이후 데이터를 노출할 수 있다. “유출된 인증 데이터로 재사용 가능한 비밀을 얻기 어렵다”와 “서버가 공격받아도 안전하다”는 다른 주장이다.

가짜 로그인 화면에 강한 이유는 도메인 결합에 있다

비밀번호는 사람이 입력할 수 있는 문자열이다. 진짜 사이트와 닮은 화면에 사용자가 그 문자열을 넣으면, 화면을 만든 쪽이 이를 받아 다른 곳에서 다시 사용할 수 있다. 일회용 코드도 사용 시점과 방식에 따라 전달될 수 있으므로, 코드의 수명이 짧다는 것만으로 피싱 저항성이 성립하는 것은 아니다.

WebAuthn의 자격증명은 등록된 RP ID, 즉 인증을 받는 서비스의 식별 범위에 묶인다. 브라우저와 인증기, 서버의 origin 검증이 함께 작동해야 한다. 가짜 도메인이 진짜 서비스의 자격증명을 같은 방식으로 요청해 가져다 쓰는 것을 제한하는 구조다. RP ID와 허용 origin을 넓게 잡거나 검증을 잘못 구현하면 이 경계가 달라질 수 있다.

NIST의 인증 지침은 피싱 저항성을 검증자와의 결합 등으로 설명하며 동기화 가능한 인증기의 조건도 따로 다룬다. 여기서 참고할 점은 인증 수단의 이름보다 어떤 대상에 어떤 증명을 만드는지 봐야 한다는 것이다. 이 지침을 한국의 모든 웹서비스에 그대로 적용되는 법적 의무로 제시하는 것은 아니다.

사용자는 여전히 사기성 사이트에서 다른 정보를 입력하거나, 정당하지 않은 작업을 승인하도록 유도될 수 있다. 패스키의 피싱 저항성은 특정 인증정보 탈취 경로를 강하게 제한하는 특성이며, 모든 사회공학을 무효화하는 기능이 아니다.

동기화형과 기기 종속형은 분실 문제에 다르게 답한다

기기 하나에만 키가 있고 그 기기를 잃으면 복구가 어렵다. 여러 기기에서 패스키를 사용할 수 있도록 동기화하면 한 기기의 분실에 대한 복원력을 높일 수 있다. 대신 키가 어떤 공급자의 저장·동기화·복구 체계에 속하는지 함께 이해해야 한다.

동기화형 패스키는 암호화된 자격증명 정보를 공급자의 체계로 여러 기기에 전달할 수 있다. 기기 종속형은 특정 인증기에 키가 남는 구성을 뜻한다. 물리 보안키, 플랫폼 인증기, 동기화 기능의 조합이 존재하므로 “보안키처럼 보인다”거나 “휴대폰에 있다”는 외형만으로 이동 가능성을 단정하면 안 된다.

비교 관점	동기화형에서 볼 점	기기 종속형에서 볼 점
기기 하나 분실	다른 승인 기기에서 계속 쓸 수 있는가	별도 등록한 예비 인증기가 있는가
모든 기기 분실	동기화 계정·키 저장소의 복구 조건	서비스 자체 계정 복구 절차
조직 통제	개인 계정 동기화·공유를 어떻게 제한하는가	등록·회수·교체를 누가 관리하는가
사용자 경험	기기 간 사용과 이전의 지원 범위	추가 기기 등록과 휴대 부담
사고 대응	어느 기기·키·세션을 폐기해야 하는가	잃은 인증기와 계정의 연결을 어떻게 끊는가

이 표는 어느 쪽이 항상 더 안전하다는 순위가 아니다. 개인 서비스의 분실 복원력과 기업의 통제 요구는 다를 수 있다. 인증기의 비밀을 내보낼 수 없어야 하는 보안 수준을 요구한다면, 동기화 가능성은 별도로 검토할 조건이 된다.

Apple 사례로 보는 ‘계정 로그인’과 ‘키 복구’의 구분

Apple의 패스키 보안 설명은 iCloud Keychain의 종단 간 암호화와 기기 간 동기화, 키체인 복구를 구분해서 설명한다. 새 기기에서 계정에 접속하는 것과 암호화된 키체인에 접근하는 것은 단일한 확인 한 번으로 취급되지 않는다. 이 구조는 동기화 계정의 비밀번호 하나만으로 모든 패스키를 곧바로 읽을 수 있다고 단순화하면 안 되는 사례다.

여기서 다른 공급자에도 그대로 적용할 수 있는 것은 구체적인 복구 단계가 아니라 질문의 틀이다. 새 기기를 누가 승인하는지, 기존 기기가 전혀 없으면 무엇으로 복구하는지, 실패한 복구 시도를 어떻게 제한하는지, 키 저장소의 암호화와 계정 인증이 어떻게 연결되는지 확인해야 한다.

공급자의 구현 설명은 그 설계를 이해하는 근거다. 우리가 해당 공급자를 공격해 복구 보안을 검증했다는 뜻은 아니다. 운영체제·제품 버전이나 서비스 정책에 따라 지원 절차가 달라질 수 있으므로 실제 이전·분실 대응은 사용 중인 공급자의 현행 안내를 따라 확인해야 한다.

로그인만 강화하고 복구를 그대로 두면

서비스가 패스키 로그인을 도입하면서 기존 비밀번호 재설정과 SMS 복구를 그대로 유지할 수 있다. 사용자의 접근성을 보장하기 위한 과도기적 선택일 수 있지만, 전체 계정 탈취 위험은 그 대체 경로의 영향을 계속 받는다.

가상의 서비스가 로그인 때는 강한 도메인 결합을 사용하면서, 고객지원 문의만으로 인증 수단을 교체해 준다고 하자. 공격자는 로그인 암호기술을 깨는 대신 약한 교체 절차를 노릴 수 있다. 이 예시는 실제 사고 보고가 아니라 계정의 전체 경로를 분석하기 위한 상황이다.

복구를 지나치게 어렵게 만들면 정당한 사용자가 계정을 영구적으로 잃을 수 있다. 따라서 “복구를 없애면 안전하다”가 해결책은 아니다. 새 인증 수단의 등록과 기존 수단의 제거, 중요한 변경 후 알림과 세션 재확인, 분실 상태에서의 지원 절차를 함께 설계해야 한다. 어떤 확인 강도가 적절한지는 서비스가 보호하는 데이터와 작업의 영향에 달려 있다.

개인이 점검할 수 있는 실용적인 질문도 여기서 나온다. 지금 로그인한 기기를 잃어도 접속할 경로가 있는지, 그 경로가 공식적으로 설명돼 있는지, 계정에 연결된 인증 수단과 기기 목록을 확인할 수 있는지다. 자신의 패스키·복구 코드를 타인에게 보여 주며 시험할 필요는 없다.

로그인 이후의 세션은 별개의 자산이다

로그인이 끝난 뒤 웹서비스는 보통 세션을 발급해 후속 요청을 처리한다. 패스키가 로그인 순간의 증명을 강하게 만들더라도, 이후 세션이 악성코드나 애플리케이션 결함으로 노출되는 문제까지 자동으로 막는 것은 아니다.

따라서 도입 조직은 인증과 세션을 다른 관측 대상으로 다뤄야 한다. 중요한 작업에서 재인증을 요구하는지, 잃은 기기의 세션을 회수할 수 있는지, 비정상적 사용을 탐지하는지, 로그아웃과 만료가 실제로 적용되는지 등을 확인해야 한다. 이들은 패스키의 대안이 아니라 서로 다른 공격 구간을 다루는 보호다.

위협·문제	패스키가 직접 바꾸는 부분	별도로 필요한 판단
비밀번호 재사용·유출	공유 비밀 기반 로그인을 줄임	남은 대체 로그인과 서버 보안
가짜 사이트에서 인증정보 탈취	서비스 결합과 서명으로 제한	origin 검증·사용자 혼동·다른 정보 입력
기기 분실	구현에 따라 동기화·예비 인증 가능	등록·폐기·복구 정책
인증 후 세션 유출	직접 해결하는 범위가 아님	세션 저장·만료·회수와 앱 보안
잘못된 업무 승인	사용자 인증을 제공	실제 작업 대상·권한·의도 확인

도입의 성공을 로그인 버튼 수로 세지 않는다

패스키 등록 수가 늘어도 사용자 대부분이 복구 과정에서 실패하거나, 중요한 계정이 약한 대체 인증에 의존하면 도입의 목적을 충분히 달성했다고 보기 어렵다. 등록 완료와 실제 로그인 성공, 분실 후 정당한 복구, 인증 수단 회수까지 나눠 관측할 이유가 있다.

성공률을 측정한다면 기기·브라우저·기존 계정 유무·동기화 지원 여부를 구분해야 한다. 실패한 로그인에 정당한 거절이 포함됐는지도 봐야 한다. 이 글은 그러한 측정 기준을 제안하지만 특정 서비스의 전환율이나 계정 탈취 감소율을 만들어 제시하지 않는다.

패스키의 강점은 비밀 문자열을 사람에게 기억시키고 매번 입력하게 하는 구조에서 벗어나, 서비스에 묶인 암호학적 증명으로 로그인하는 데 있다. 그 이점을 유지하려면 복구와 세션을 같은 계정 체계 안에서 함께 설계해야 한다. 로그인 화면을 바꾸는 일과 계정을 보호하는 일의 범위를 나누어 보는 것이 출발점이다.