우리 웹서비스에도 패스키 로그인을 도입해야 할까? 사업자가 먼저 따져볼 기준

회원이 반복해서 로그인하는 웹서비스라면 패스키를 검토할 만합니다. 다만 기존 비밀번호 로그인을 한 번에 없애기보다 패스키를 선택지로 추가하고, 계정 복구와 새 기기 전환이 제대로 되는지 먼저 확인하는 편이 안전합니다. 패스키는 공개 키 암호화를 이용하며 사용자는 지문, 얼굴 인식, 기기 PIN처럼 평소 화면 잠금을 푸는 방법으로 로그인합니다.[1][3]

패스키가 비밀번호와 다른 점

비밀번호는 사용자가 문자열을 기억하거나 비밀번호 관리 프로그램에 저장한 뒤 서버에 제출하는 방식입니다. 패스키에서는 서비스가 공개 키를 보관하고, 사용자의 기기나 패스키 제공자가 개인 키를 관리합니다. 로그인할 때 개인 키 자체를 서버에 보내는 대신 요청에 대한 암호학적 서명을 확인합니다.[1]

웹 인증 표준인 WebAuthn은 공개 키 자격 증명을 특정 서비스의 범위에 묶습니다. 다른 출처의 사이트가 같은 자격 증명을 마음대로 요청할 수 없도록 설계되어 피싱 저항성을 갖습니다.[1] 사용자가 보는 화면에서는 복잡한 키가 드러나지 않습니다. 기기 잠금을 풀 때처럼 본인 확인을 하면 됩니다.[3]

여기서 자주 생기는 오해가 하나 있습니다. 지문이나 얼굴 정보가 홈페이지 서버로 전송되는 것은 아닙니다. 생체 정보는 기기에서 사용자를 확인하는 수단이며, 웹서비스는 인증 결과에 필요한 서명을 받습니다.[1][3]

모든 홈페이지에 지금 필요한 기능은 아니다

단순 회사 소개 사이트나 로그인 자체가 없는 랜딩페이지라면 패스키를 넣을 이유가 없습니다. 개발과 테스트 범위만 늘어납니다. 반대로 고객이 주문 내역, 예약, 구독, 업무 자료를 확인하려고 자주 돌아오는 서비스라면 로그인 과정이 제품 경험의 일부입니다. 이때는 검토 가치가 커집니다.

다음 질문 중 두 개 이상에 해당하면 후보로 올려볼 수 있습니다.

• 고객이 한 달에 여러 번 로그인한다.
• 비밀번호 찾기 문의가 운영 부담으로 이어진다.
• 예약 변경이나 결제 정보 수정처럼 다시 본인을 확인해야 하는 작업이 있다.
• 기업 고객이나 관리자 계정의 피싱 위험을 줄여야 한다.
• 모바일과 PC를 오가며 쓰는 회원이 많다.

패스키는 동기화형과 기기 종속형으로 나뉩니다. 동기화형은 같은 패스키 제공자를 쓰는 여러 기기에서 사용할 수 있고, 기기 종속형은 특정 기기나 보안 키에 머뭅니다.[3] 일반 고객 서비스와 내부 관리자 시스템은 요구 조건이 다르므로 한 가지 방식으로 묶어 결정하지 않는 편이 좋습니다.

도입 전에 계정 복구부터 설계해야 한다

로그인 버튼보다 먼저 그려야 할 화면은 복구 화면입니다. 휴대전화를 잃어버렸거나 운영체제를 바꾼 사람, 회사에서 지급한 기기를 반납한 사람도 계정에 돌아올 수 있어야 합니다. Google의 패스키 사용자 여정 가이드는 패스키로 새 계정을 만들 때 복구 수단을 마련하라고 권고합니다.[2]

복구 정책에는 적어도 다음 내용을 적어두는 것이 좋습니다.

1. 사용자가 두 번째 패스키를 미리 등록할 수 있는가
2. 등록된 패스키의 이름과 최근 사용 정보를 확인하고 삭제할 수 있는가
3. 사용할 수 있는 패스키가 하나도 없을 때 어떤 본인 확인을 거치는가
4. 고객센터 직원이 계정을 복구할 수 있다면 승인 기록과 권한을 어떻게 남기는가
5. 복구 직후 결제 정보 변경 같은 민감한 작업을 제한할 것인가

복구 절차가 너무 약하면 앞단의 로그인만 강하게 만들어도 소용이 없습니다. 반대로 복구 조건이 지나치게 까다로우면 정상 고객이 계정을 포기할 수 있습니다. 보안팀, 운영팀, 고객지원 담당자가 같은 흐름을 보고 기준을 정해야 합니다.

비밀번호를 없애기보다 선택 기능으로 시작한다

첫 배포에서는 기존 로그인 폼을 유지하는 편이 현실적입니다. 로그인에 성공한 회원에게 패스키 등록을 제안하거나, 계정 설정의 보안 메뉴에서 직접 등록하게 할 수 있습니다. Google도 로그인 중, 계정 보안 설정, 계정 복구 뒤, 재인증 뒤를 패스키 생성 제안 시점으로 안내합니다.[2]

권장 순서는 다음과 같습니다.

1. 직원 또는 소수 테스트 계정에만 기능을 연다.
2. 기존 방식으로 로그인한 뒤 패스키를 추가하도록 한다.
3. 등록 성공과 취소, 이미 등록된 경우를 각각 확인한다.
4. 같은 운영체제 안의 새 기기와 서로 다른 운영체제 사이의 로그인을 시험한다.
5. 패스키 이름 변경, 추가 등록, 삭제, 계정 복구를 끝까지 실행한다.
6. 오류율, 완료율, 고객 문의 유형을 기존 로그인과 나눠 관찰한다.

패스키가 없는 기기에서도 다른 기기의 패스키를 이용하는 교차 기기 인증 흐름이 있습니다.[3] 그렇다고 안내 문구 없이 운영체제의 QR 화면부터 띄우면 사용자는 무엇을 해야 하는지 알기 어렵습니다. 시스템 창을 열기 전에 필요한 기기와 다음 동작을 짧게 설명하고, 취소해도 기존 로그인으로 돌아갈 수 있게 해야 합니다.

기획서에는 로그인 이후의 관리 화면도 넣는다

패스키 기능을 로그인 버튼 하나로 정의하면 견적과 일정이 자주 어긋납니다. 실제 범위에는 등록, 로그인, 재인증, 목록 조회, 이름 구분, 삭제, 복구가 들어갑니다. Google은 사용자가 여러 패스키를 구분할 수 있도록 출처를 표시하고 같은 생태계의 패스키가 여러 개라면 번호를 붙이라고 권고합니다.[2]

화면별로 성공 상태와 실패 상태도 필요합니다. 예를 들어 등록 도중 사용자가 취소했을 때 계정이 잠기면 안 됩니다. 마지막 패스키를 삭제하려는 회원에게 남은 로그인 수단을 알려줘야 합니다. 민감한 설정을 바꾸기 전에는 현재 세션만 믿지 않고 다시 인증하는 흐름도 검토해야 합니다.

개발사에 요청할 때는 다음 산출물을 범위에 명시하세요.

• 지원할 브라우저와 운영체제 조합
• 패스키 등록 및 로그인 화면
• 등록된 패스키 관리 화면
• 기기 분실과 계정 복구 절차
• 기존 비밀번호 또는 소셜 로그인과의 공존 기간
• 관리자용 문의 대응 기준과 감사 기록
• 테스트 계정, 오류 기록, 배포 후 관찰 항목

개발 검수에서 놓치기 쉬운 항목

WebAuthn 자격 증명은 서비스의 Relying Party, 즉 인증을 요청하는 주체의 범위에 묶입니다.[1] 도메인과 서브도메인 구성이 바뀔 예정이라면 개발 시작 전에 로그인 범위를 정해야 합니다. 운영 주소와 테스트 주소도 구분해 검증해야 합니다.

브라우저가 제공하는 인증 창만 확인하고 끝내지 마세요. 서버가 로그인 요청을 만들고 응답을 검증하는 과정, 사용자 계정과 공개 키를 연결하는 저장 구조, 삭제된 자격 증명의 처리까지 함께 점검해야 합니다. 개인정보 처리방침과 고객센터 안내에도 패스키를 어디에서 관리하고 어떻게 복구하는지 반영할 필요가 있습니다.

출시 전에는 최소한 아래 상황을 실제 기기로 확인합니다.

• 정상 등록과 정상 로그인
• 사용자가 등록 창이나 로그인 창을 취소한 경우
• 한 계정에 패스키를 두 개 이상 등록한 경우
• 등록한 패스키를 삭제한 뒤 다시 로그인하는 경우
• 휴대전화의 패스키로 PC에 로그인하는 경우
• 패스키를 사용할 수 없어서 복구 절차로 넘어가는 경우
• 세션이 만료된 뒤 민감한 작업을 다시 인증하는 경우

도입 여부는 로그인 빈도와 복구 준비로 결정한다

패스키는 회원제 서비스의 보안과 로그인 경험을 손볼 수 있는 선택지입니다. 그러나 로그인 빈도가 낮고 비밀번호 관련 문의도 거의 없다면 다른 개선이 먼저일 수 있습니다. 반대로 반복 로그인과 계정 복구가 운영 문제로 드러났다면 작은 사용자군부터 패스키를 추가해 볼 근거가 충분합니다.

의사결정 문서에는 '패스키를 도입한다'보다 대상 사용자, 유지할 기존 로그인 수단, 복구 방식, 지원 기기, 성공 판단 지표를 적는 편이 유용합니다. 인증 구조와 계정 관리 화면을 함께 설계해야 한다면 웹서비스 개발 범위를 정할 때 이 다섯 항목부터 확인해 보세요.