사전 패스키
개념

패스키

gabury1고친 사람 github-actions[bot]

패스키는 비밀번호 없이 웹사이트와 앱에 로그인하게 해 주는 방법입니다. 사용자는 외울 것이 없습니다. 휴대폰 잠금을 풀듯 지문이나 화면 잠금으로 확인만 하면 됩니다. 서버에는 훔쳐 가도 쓸모없는 값만 남습니다.

쉽고 빠른 이해

비밀번호 대신 기기 안에 든 열쇠로 로그인하는 방법입니다. 로그인 버튼을 누르면 휴대폰이 지문을 묻습니다. 지문이 맞으면 로그인이 끝납니다.

비밀번호는 한 번 새면 누구나 씁니다. 가짜 로그인 화면에 적어 넣은 비밀번호도, 서버에서 털린 비밀번호도 공격자가 그대로 입력합니다. 패스키에는 사용자가 적어 넣을 글자가 없습니다. 서버가 가진 값으로는 로그인을 흉내 낼 수 없습니다.

어떻게 도나:

  1. 가입할 때 기기가 그 사이트 전용 열쇠 한 쌍을 만듭니다. 한쪽은 기기에 둡니다. 짝만 서버에 맡깁니다
  2. 로그인할 때 서버가 매번 다른 문제를 냅니다. 기기가 자기 열쇠로 답을 만듭니다
  3. 서버는 맡아 둔 짝으로 그 답이 맞는지 확인합니다

대가도 있습니다. 기기를 전부 잃으면 계정을 되찾는 절차가 따로 필요합니다. 열쇠를 여러 기기에 복사해 주는 클라우드 계정이 새로운 급소가 됩니다.

그래서 뚫리면 피해가 큰 계정부터 겁니다. 관리자 계정이나 돈이 움직이는 계정이 그렇습니다.

상세

관공서에 인감도장을 등록해 두는 일을 떠올려 봅니다. 도장은 주인의 서랍 안에만 있습니다. 관공서는 도장 자국만 보관합니다. 서류가 들어오면 찍힌 자국을 보관한 자국과 맞춰 봅니다.

패스키는 비밀번호 대신 쓰는 로그인 수단입니다. 속은 인감도장과 같은 짜임입니다. 도장에 해당하는 키는 사용자의 기기 안에만 있습니다. 서버는 도장 자국에 해당하는 짝 키만 보관합니다.

예를 들어 쇼핑몰에 패스키를 등록해 두면 다음 로그인 때 아이디와 비밀번호를 적지 않습니다. 「패스키로 로그인」 버튼을 누릅니다. 휴대폰에 지문을 한 번 대면 로그인이 끝납니다.

비밀번호가 새는 길

비밀번호는 서버와 사용자가 같은 글자를 나눠 아는 방식입니다. 서버는 받은 글자가 저장한 값과 맞는지만 봅니다. 그 글자를 누가 입력했는지는 구별하지 못합니다.

새는 길 하나는 사용자가 직접 넘겨주는 것입니다. 진짜처럼 꾸민 가짜 로그인 화면에 사용자가 비밀번호를 적습니다. 이 속임수가 피싱입니다.

다른 길은 서버 쪽입니다. 서버는 비밀번호를 원래 글자로 되돌릴 수 없게 섞어서 저장합니다. 이것이 비밀번호 해싱입니다.

그래도 서버에서 털린 값으로 흔한 비밀번호는 알아낼 수 있습니다. 공격자는 흔한 비밀번호를 같은 방식으로 섞어 봅니다. 그 결과가 털린 값과 같으면 원래 비밀번호를 찾은 것입니다.

비밀번호를 여러 사이트에 같이 쓰면 피해가 번집니다. 공격자는 한 사이트에서 얻은 아이디와 비밀번호를 다른 사이트에 차례로 넣어 봅니다. 이 공격의 이름은 크리덴셜 스터핑입니다.

패스키는 두 길을 모두 끊습니다. 사용자에게는 적어 넣을 글자가 없습니다. 서버에는 공개해도 되는 값만 있습니다.

공개 키 암호와 전자 서명

패스키가 서버에 비밀을 두지 않을 수 있는 것은 공개 키 암호 덕분입니다. 공개 키 암호는 짝을 이루는 키 두 개를 씁니다.

하나는 주인만 갖는 개인 키입니다. 앞에서 도장에 빗댄 키입니다. 다른 하나는 남에게 줘도 되는 공개 키입니다. 도장 자국에 빗댄 키입니다.

공개 키로는 개인 키를 알아낼 수 없습니다. 공개 키가 서버에서 털려도 공격자는 개인 키를 만들지 못합니다.

전자 서명은 개인 키로 어떤 값에 남기는 표시입니다. 개인 키를 가진 쪽만 서명을 만들 수 있습니다. 짝이 되는 공개 키가 있으면 누구나 그 서명이 맞는지 확인할 수 있습니다.

패스키 로그인은 이 서명 하나로 이뤄집니다. 기기가 서명합니다. 서버는 그 서명을 확인합니다. 서버는 비밀을 갖지 않고도 상대가 개인 키를 가졌는지 알아냅니다.

키를 만들고 지키는 인증기

개인 키를 만들고 보관하는 부분을 인증기라고 합니다. 영어로는 authenticator 입니다. 서명도 인증기가 합니다. 휴대폰이나 노트북에 들어 있는 보안 칩이 흔한 인증기입니다. 열쇠고리만 한 보안 키를 컴퓨터에 꽂아 쓰기도 합니다.

인증기는 서명하기 전에 사용자에게 확인을 받습니다. 지문이나 얼굴, 또는 PIN(Personal Identification Number, 개인 식별 번호)으로 잠금을 풉니다. 기기를 주운 사람이 바로 로그인하지 못하게 하려는 확인입니다.

이 확인은 기기 안에서 끝납니다. 지문 정보는 서버로 가지 않습니다. 서버가 받는 것은 서명뿐입니다. 지문은 개인 키를 꺼내 쓰게 하는 잠금일 뿐입니다.

등록 과정

처음 패스키를 만들 때는 키 한 쌍을 새로 만듭니다. 그중 공개 키를 서버에 맡깁니다. 이 흐름에는 서버, 브라우저, 인증기 셋이 나옵니다. 브라우저는 서버와 인증기 사이에서 요청을 전합니다.

셋이 주고받는 약속은 WebAuthn(Web Authentication)이 정합니다. WebAuthn 은 웹 페이지가 브라우저에 패스키 등록과 로그인을 요청하는 방법을 정한 웹 표준입니다. 주고받는 데이터의 모양도 여기서 정합니다. 패스키 로그인은 이 약속 위에서 돕니다.

키 쌍은 사이트마다 따로 만듭니다. 사이트를 가르는 기준은 도메인입니다. 도메인은 shop.example.com 처럼 주소창에 보이는 사이트 이름입니다. 브라우저가 지금 페이지의 도메인을 인증기에 알려 줍니다.

크리덴셜 ID는 이때 생기는 이름표입니다. 한 사용자가 패스키를 여러 개 가질 수 있습니다. 서버는 이 이름표로 어느 키 쌍인지 가립니다.

sequenceDiagram
    participant 서버
    participant 브라우저
    participant 인증기
    서버->>브라우저: 이 사이트용 패스키를 만들어 달라
    브라우저->>인증기: 도메인과 함께 요청을 전한다
    Note over 인증기: 사용자가 지문이나 PIN 으로 확인한다
    Note over 인증기: 키 한 쌍을 만들고 개인 키를 보관한다
    인증기-->>브라우저: 공개 키와 크리덴셜 ID
    브라우저-->>서버: 공개 키와 크리덴셜 ID
    Note over 서버: 사용자 계정에 공개 키를 저장한다

그림에서 개인 키는 인증기를 떠나지 않습니다. 서버까지 가는 것은 공개 키와 크리덴셜 ID 둘입니다. 인증기는 이 키 쌍이 어느 도메인용인지도 함께 기록합니다.

로그인 과정

로그인할 때 서버는 먼저 챌린지를 보냅니다. 챌린지는 서버가 매번 새로 만드는 임의의 값입니다. 인증기가 이 값에 서명해 돌려주면 서버가 확인합니다.

sequenceDiagram
    participant 서버
    participant 브라우저
    participant 인증기
    서버->>브라우저: 챌린지
    브라우저->>인증기: 챌린지와 지금 페이지의 도메인
    Note over 인증기: 사용자가 지문이나 PIN 으로 잠금을 푼다
    인증기-->>브라우저: 개인 키로 만든 서명
    브라우저-->>서버: 서명과 크리덴셜 ID
    Note over 서버: 저장해 둔 공개 키로 서명을 확인한다

챌린지가 매번 바뀌는 까닭은 서명을 다시 쓰지 못하게 하려는 것입니다. 지난번 서명을 가로챈 공격자가 그것을 다시 보내도 이번 챌린지와 맞지 않습니다. 가로챈 값을 다시 보내는 이 공격이 재전송 공격입니다.

브라우저는 챌린지와 함께 지금 페이지의 도메인을 인증기에 넘깁니다. 인증기가 그 도메인용 키를 골라 서명하게 하려는 것입니다. 이 도메인이 피싱을 어떻게 막는지는 아래 「가짜 사이트에서 쓰이지 않는 까닭」에서 봅니다.

패스키는 아이디 입력도 덜어 줍니다. 인증기는 이 사이트용으로 가진 패스키를 알고 있습니다. 그래서 사용자는 아이디를 적는 대신 목록에서 계정을 고르기만 하면 됩니다.

가짜 사이트에서 쓰이지 않는 까닭

이 절은 피싱을 막는 장치 둘을 봅니다. 하나는 사용자의 기기 쪽에서 막습니다. 다른 하나는 서버 쪽에서 막습니다.

첫째 장치는 도메인입니다. 앞에서 본 대로 패스키는 만들 때 도메인에 묶입니다. 로그인할 때 지금 페이지의 도메인은 사용자가 아니라 브라우저가 인증기에 알려 줍니다. 생김새가 비슷한 가짜 도메인용 키는 처음부터 없으므로 인증기는 서명을 만들지 않습니다.

둘째 장치는 서명 안에 든 주소입니다. 브라우저는 지금 열린 페이지의 오리진을 서명할 값에 넣습니다. 오리진은 프로토콜, 도메인, 포트를 묶은 웹 주소 단위입니다. https://shop.example.com 이 오리진 하나입니다.

서명 안의 오리진은 공격자가 바꿀 수 없습니다. 바꾸면 서명이 맞지 않게 됩니다. 서버는 그 오리진이 자기 사이트의 것이 아니면 로그인을 거절합니다.

두 장치 덕분에 사용자가 가짜 화면에 속아도 로그인 수단은 넘어가지 않습니다. 휴대폰 앱의 숫자를 옮겨 적는 일회용 비밀번호는 다릅니다. 사용자가 가짜 화면에 숫자를 적으면 공격자가 그 숫자를 진짜 사이트에 바로 넣을 수 있습니다.

여러 기기에서 쓰는 방법

패스키를 만든 기기를 잃으면 그 개인 키도 함께 사라집니다. 이 문제를 푸는 방법이 둘로 갈립니다.

하나는 개인 키를 사용자의 클라우드 계정에 암호화해 올려 두는 방식입니다. 같은 계정으로 로그인한 새 휴대폰에 패스키가 따라옵니다. 운영체제나 비밀번호 관리자가 이 일을 맡습니다. 이런 패스키를 동기화되는 패스키라고 합니다.

다른 하나는 개인 키를 한 기기 안에만 두는 방식입니다. 보안 키에 만든 패스키가 대표적입니다. 이 개인 키는 복사되지 않습니다.

두 방식은 기기를 잃었을 때 무엇이 남는지가 다릅니다.

동기화되는 패스키 기기에 묶인 패스키
개인 키가 있는 곳 여러 기기와 클라우드 계정 그 기기 하나
기기를 잃으면 새 기기에 다시 내려받습니다 그 패스키는 못 씁니다
공격자가 노릴 곳 클라우드 계정 그 기기 자체

표의 마지막 줄이 두 방식의 대가입니다. 동기화되는 패스키는 새 기기로 쉽게 옮겨 갑니다. 대신 클라우드 계정이 뚫리면 패스키도 넘어갑니다. 기기에 묶인 패스키는 그 위험이 없는 대신 기기마다 따로 등록해야 합니다.

패스키가 없는 컴퓨터에서 로그인해야 할 때도 있습니다. 이때는 그 컴퓨터 화면에 뜬 QR 코드(Quick Response Code)를 휴대폰으로 찍습니다. 로그인은 휴대폰에 든 패스키로 합니다.

이 방식에서는 두 기기가 가까이 있는지를 블루투스로 확인합니다. 멀리 있는 공격자의 컴퓨터가 띄운 QR 코드를 사용자가 속아서 찍는 일이 있기 때문입니다. 가까이 있지 않은 컴퓨터에는 로그인이 이어지지 않습니다.

다중 인증과의 관계

다중 인증은 성격이 다른 증거를 둘 이상 받는 로그인입니다. 증거의 종류는 흔히 아는 것, 가진 것, 그 자신인 것으로 나눕니다.

패스키 로그인은 한 번에 두 종류를 씁니다. 개인 키가 든 기기는 가진 것입니다. 그 기기의 잠금을 푸는 지문은 그 자신인 것입니다. PIN 은 아는 것입니다.

패스키 하나로 증거 두 종류가 채워집니다. 비밀번호 없이 혼자서 로그인을 끝낼 수 있는 까닭입니다. 비밀번호를 받은 뒤 두 번째 증거로 패스키를 묻는 사이트도 있습니다.

서버가 할 일

WebAuthn 에서는 패스키로 로그인을 받는 사이트 쪽을 신뢰 당사자(relying party)라고 부릅니다. 사용자의 서명을 믿고 로그인을 내주는 쪽이라는 뜻입니다. 이 절에서 말하는 서버가 신뢰 당사자입니다.

패스키를 붙이는 백엔드 개발자가 먼저 정할 것은 무엇을 저장하느냐입니다. 비밀번호 해시 대신 아래 값을 둡니다.

저장하는 값 쓰임
크리덴셜 ID 로그인 요청이 어느 키 쌍의 것인지 찾습니다
공개 키 서명이 맞는지 확인합니다
사용자 ID 그 키 쌍이 어느 계정의 것인지 잇습니다

한 사용자는 휴대폰, 노트북, 보안 키에 패스키를 하나씩 둘 수 있습니다. 계정 하나에 패스키 여러 개가 붙는 일대다 관계로 저장합니다. 하나를 잃어도 다른 패스키로 들어올 수 있습니다.

로그인 요청이 오면 신뢰 당사자 서버는 세 가지를 봅니다. 먼저 챌린지가 서버가 방금 낸 값인지 봅니다. 그 챌린지가 처음 쓰였는지도 봅니다. 다음으로 서명한 값에 든 오리진이 우리 사이트의 것인지 봅니다. 마지막으로 저장한 공개 키로 서명을 확인합니다.

셋 중 하나라도 빠지면 막으려던 공격이 다시 통합니다. 챌린지 검사가 빠지면 재전송 공격이 통합니다. 오리진 검사가 빠지면 피싱이 통합니다. 이 검사들은 서버 라이브러리에 맡길 수 있습니다. WebAuthn 이 정한 데이터를 풀어 세 검사를 대신 해 주는 라이브러리입니다.

대가와 쓰는 때

모든 패스키를 잃은 사용자는 계정을 되찾을 길이 따로 있어야 합니다. 그 길이 이메일 링크 하나라면 공격자는 로그인 대신 그 길로 들어옵니다. 복구 경로에도 로그인과 같은 무게의 확인을 겁니다.

패스키를 지원하지 않는 기기와 브라우저가 남아 있습니다. 그래서 많은 사이트가 비밀번호 로그인을 함께 남깁니다. 비밀번호가 살아 있는 동안에는 그 비밀번호가 여전히 피싱의 표적입니다.

먼저 거는 곳은 뚫렸을 때 피해가 큰 계정입니다. 관리자 계정, 돈이 움직이는 계정, 서버와 클라우드 설정을 바꾸는 계정이 그렇습니다. 일반 사용자 로그인에서는 비밀번호를 자주 잊는 서비스일수록 패스키가 로그인 한 단계를 줄여 줍니다.

관련 항목

패스키를 받치는 암호 기술

공개 키 암호 · 개인 키 · 공개 키 · 전자 서명 · 챌린지-응답 인증 · 해시 함수

패스키를 정의하는 표준·규격

WebAuthn · FIDO2 · CTAP · U2F · FIDO 얼라이언스

패스키를 만들고 잠그는 장치

인증기 · 보안 키 · TPM · 비밀번호 관리자 · 생체 인증 · PIN

패스키가 대신하는 로그인 수단

비밀번호 · 일회용 비밀번호 · TOTP · 매직 링크 · 다중 인증

패스키가 막는 공격

피싱 · 크리덴셜 스터핑 · 재전송 공격 · 중간자 공격 · 비밀번호 스프레이 · 계정 탈취

패스키가 묶이는 웹 주소 단위

오리진 · 도메인 이름 · 신뢰 당사자 · 동일 출처 정책

패스키와 함께 로그인을 이루는 기술

인증 · 세션 · 크리덴셜 ID · 계정 복구 · 싱글 사인온 · 비밀번호 없는 인증 · 인증과 인가

다른 이름: passkey · passkeys · 패스 키