패스키와 비밀번호 + TOTP 비교: 실시간 피싱에서 갈리는 차이

비밀번호를 입력하고, 이어서 휴대폰 앱에 뜬 6자리 코드를 입력했습니다. 그런데 그 화면이 진짜 사이트가 아니었다면 어떻게 될까요. 로그인은 성공하고, 계정은 공격자 손에 넘어갑니다. 사용자는 규칙대로 두 단계를 모두 거쳤는데도 그렇습니다.

흔히 인증은 겹칠수록 안전하다고 이해합니다. 그래서 패스키 앞에도 비밀번호를 한 겹 더 붙이면 낫다고 생각하기 쉽습니다. 저는 이 직관이 절반만 맞다고 봅니다. 겹이 늘어도 막는 공격이 늘지 않는 경우가 있고, 패스키 앞의 비밀번호가 그런 경우입니다.

두 단계를 거치고도 뚫리는 중계 피싱

TOTP는 서버와 휴대폰이 같은 비밀키로 30초마다 같은 6자리를 계산하는 방식입니다(RFC 6238). 코드는 사람이 눈으로 보고 옮겨 적는 값이어서, 입력을 받는 쪽이 진짜 서버인지 확인하는 단계가 어디에도 없습니다. 가짜 페이지가 받은 비밀번호와 코드를 그 자리에서 진짜 사이트에 그대로 넘기면, 진짜 사이트는 정상 로그인으로 처리합니다. 30초는 사람이 속아서 입력하고 넘기기에 충분한 시간입니다.

가짜 주소는 생각보다 눈에 띄지 않습니다. 휴대폰에서는 주소창이 잘려 보이고, 대문자 I와 소문자 l처럼 모양이 같은 글자도 있습니다. "속지 않도록 조심하라"는 해법을 저는 믿지 않습니다. 속은 사람은 속았다는 사실을 모르기 때문입니다.

NIST의 디지털 신원 지침(SP 800-63B)에는 인증 방식이 사칭 사이트에 얼마나 저항하는지를 따지는 항목이 있고, 사용자가 옮겨 적는 일회용 코드는 이 저항이 약한 쪽으로 분류됩니다. 정확한 절 번호는 판본마다 달라서 여기에는 적지 않습니다.

사람의 눈 대신 브라우저가 도메인을 확인하는 구조

패스키(WebAuthn, W3C)는 키를 만들 때 그 사이트의 도메인(RP ID)을 함께 묶어 둡니다. 로그인할 때 브라우저는 지금 열린 페이지의 오리진을 서명할 데이터에 넣고, 기기는 묶여 있는 도메인과 맞지 않으면 키를 쓰지 않습니다. 가짜 주소에서는 패스키 선택 창에 후보가 뜨지도 않습니다. 확인하는 주체가 사람의 눈에서 브라우저와 기기로 옮겨 간 것입니다.

서버에는 공개키만 남고 비밀키는 기기를 떠나지 않습니다. 서버 DB가 통째로 유출돼도 그 값으로는 로그인할 수 없습니다. 키는 사이트마다 따로 만들어지므로 다른 곳에서 재사용되는 일도 없습니다.

패스키 한 번에 들어 있는 두 요소

패스키 로그인은 기기를 가지고 있다는 것과, 지문이나 PIN으로 기기 잠금을 풀었다는 것을 함께 요구합니다. 비밀번호를 앞에 붙이는 일이 의미를 잃는 이유가 여기 있습니다. 원격에서 들어오려는 공격자는 패스키가 없어서 이미 막히고, 기기를 훔친 사람은 잠금을 풀어야 해서 막힙니다. 비밀번호가 추가로 막아 주는 시나리오를 꼽아 보면 거의 남지 않습니다.

반대로 늘어나는 것은 있습니다. 비밀번호가 있으면 유출, 재사용, 피싱의 대상이 하나 더 생깁니다. 여기서 중요한 구분이 하나 있습니다. 패스키 앞에 비밀번호를 얹는 것과, 패스키와 별개로 비밀번호 로그인 길을 열어 두는 것은 다릅니다. 뒤쪽이라면 공격자는 가장 약한 입구를 고르므로, 패스키가 아무리 강해도 전체 강도는 비밀번호 길이 정합니다.

방식	유출된 비밀번호	실시간 피싱
비밀번호만	뚫림	뚫림
비밀번호 + TOTP	막음	뚫림
패스키만	해당 없음	막음
비밀번호 + 패스키	막음	막음(패스키 덕분)

마지막 줄이 핵심입니다. 비밀번호를 더해서 얻은 것이 아니라 패스키가 이미 하던 일을 표에 한 번 더 적은 것입니다.

패스키가 지키지 못하는 로그인 이후

패스키가 지키는 것은 로그인하는 순간입니다. 로그인이 끝난 뒤 발급되는 세션 쿠키를 훔치면 인증 자체를 건너뛸 수 있고, 기기가 이미 악성코드에 감염됐다면 로그인된 화면을 통째로 가져갈 수 있습니다. 이 둘은 인증 수단을 바꿔서는 막히지 않습니다. 세션 수명을 짧게 두고, 쿠키를 HttpOnly와 Secure로 발급하고, 민감한 작업 앞에서 다시 인증을 요구하는 쪽에서 막아야 합니다.

동기화 패스키와 하드웨어 키의 강도 차이

패스키라고 해서 모두 같은 강도는 아닙니다. iCloud 키체인이나 구글 비밀번호 관리자처럼 여러 기기로 동기화되는 패스키는 편하고 기기를 바꿔도 이어집니다. 대신 그 클라우드 계정이 뚫리면 패스키도 같이 위험해집니다. 하드웨어 보안키(FIDO2)는 비밀키가 장치 밖으로 나가지 않아서 가장 강하고, 대신 분실에 대비한 예비가 꼭 필요합니다.

개인이 쓰는 서비스라면 저는 동기화 패스키에 예비 패스키 하나를 더 등록하는 정도로 충분하다고 봅니다. 관리자 권한처럼 한 번 뚫리면 피해가 큰 계정이라면 하드웨어 키를 고려할 만합니다.

전체 강도를 정하는 가장 약한 복구 경로

패스키를 도입하고도 "비밀번호 찾기"가 메일 링크 하나로 되어 있다면, 공격자는 패스키를 상대하지 않고 그 메일 계정을 노립니다. 인증 수단을 강하게 만드는 일보다 복구 경로를 같은 수준으로 맞추는 일이 더 자주 빠집니다.

반대쪽 위험도 현실적입니다. 패스키를 둔 기기를 잃어버렸는데 들어갈 길이 없으면 스스로 잠깁니다. 패스키를 두 개 이상 등록하고, 백업 코드는 서비스 바깥에 오프라인으로 보관하는 정도가 최소한의 준비라고 생각합니다.

확실한 부분과 환경마다 달라지는 부분

확실한 것은 피싱 저항의 차이입니다. 패스키가 도메인에 묶인다는 점과 TOTP 코드가 옮겨 적는 값이라는 점은 각각 명세에 적혀 있는 동작입니다.

환경마다 달라지는 것도 있습니다. 동기화 패스키가 서로 다른 플랫폼 사이에서 얼마나 매끄럽게 옮겨지는지는 제가 모든 조합을 확인하지 못했습니다. 비밀번호를 완전히 없애는 것이 모든 서비스에 맞는지도 확신이 없습니다. 이용자의 기기가 제각각이어서 패스키를 쓰지 못하는 사람이 많은 서비스라면 비밀번호 경로를 남겨야 하고, 그때는 그 경로를 어떻게 지킬지가 새 과제가 됩니다.