DEVOCEAN

WebAuthn 스펙은 FIDO 스펙이 진화한 결과입니다.

애플, 구글, MS 등의 업체들이 지지하고 있으며 "패스키(Passkey)"라는 브랜드 네임으로 알려져 있습니다.

WebAuthn 스펙을 정말 잘 설명하고 있는 글이 있어 일부를 번역하여 공유합니다.

그냥 "좋은 글이 있어요"라고 링크만 소개하고 말기에는 아깝다는 생각이 들었습니다.

글의 출처는 https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html 입니다.

패스워드는

쓰레기입니다. 이 글을 읽는 분이라면 이미 이 생각에 동의하시겠지만, 왜 그런지 다시 한 번 살펴 봅시다.

사람들은 보통, 패스워드 몇 개를 여기저기 돌려씁니다.

(랜덤하게 패스워드를 만들어내는 패스워드 매니저라는 도구가 있지만, 사람들이 쓰지 않지요.)

웹사이트는 패스워드의 해시값을 저장하고, 인증할 때 이 해시값을 사용합니다.

그런데 대부분의 패스워드는 엔트로피가 낮아서, 해시값만 유출돼도 무차별 대입 공격에 의해 노출됩니다.

(haveibeenpwned.com 사이트에 의하면 대략 800 개 웹사이트에서 135억 개 계정이 유출됐다고 합니다.)

패스워드 데이터베이스가 유출되면, 패스워드가 유출된 그 웹사이트만 문제가 되는 게 아닙니다.

패스워드를 여러 곳에서 돌려쓰는 행태 때문에, 다른 웹사이트들도 문제가 됩니다.

다음으로, 패스워드는 사람이 기억하기 때문에, 비슷해 보이는 웹사이트로 사람을 속여서 패스워드를 입력하게 할 수 있습니다.

이러한 "피싱(phishing)" 공격은 흔하고 효과적입니다.

마지막으로, 패스워드는 소프트웨어 계층 여기저기서 유출될 수 있습니다.

거대 기업 페이스북조차 수억 개의 패스워드를 실수로 로깅(logging)한 적이 있습니다.

그리고 자바스크립트 인젝션 공격은 패스워드를 포함해서 웹사이트에 입력하는 모든 내용을 유출시킬 수 있습니다.

이 글은

공개키 서명 체계(public key signature scheme)를 사용해서 더 나은 인증(authentication) 시스템을 만들려는 노력에 관한 이야기입니다.

공개키 서명은 ECDSA, RSA, ML-DSA 등으로 불립니다.

이는 결과값이 얼마나 큰지, 결과값을 얻는 데 얼마나 오래 걸리는지, (아직 이론적인 이야기지만) 양자 컴퓨터 내성을 얼마나 갖고 있는지에 따른 분류입니다.

공개키 서명 체계는 세 가지 연산을 제공합니다.

1. generate 연산은 난수 비트를 받아서 공개키와 개인키라고 불리는 두 개의 바이트 문자열을 반환하는 작업입니다.

2. sign 연산은 개인키와 임의의 바이트 문자열(메시지라고 함)을 받아서 "서명(signature)"이라고 불리는 또 다른 바이트 문자열을 생성하는 작업입니다.

3. verify 연산은 공개키, 메시지, 서명 값을 받아서 해당 서명이 해당 개인키를 사용해서 생성됐는지 검증하는 작업입니다.

공개키 서명 체계가 유용하려면 다음과 같은 속성이 있어야 합니다.

1. 공개키로부터 개인키를 계산하는 것은 불가능해야 합니다.

2. 개인키 없이는 서명을 계산할 수 없어야 합니다.

다음은

공개키 서명을 사용한 인증(authentication) 방식의 간단히 예입니다.

사용자는 username과 password를 만들어 웹사이트에 등록하지 않습니다.

대신 사용자는 웹사이트에 등록하기 위해 usrename을 만든 다음 사용자의 컴퓨터에서 generate 연산을 실행해서 key pair(공개키와 개인키)를 만듭니다.

그리고 사용자의 컴퓨터에 개인키를 저장한 다음, 공개키와 username을 웹사이트에 제출합니다.

로그인할 때 사용자는 username을 입력합니다. 그러면 사용자의 컴퓨터가 사용자의 개인키를 사용해서 "let me in" 메시지에 대해 서명 값을 계산합니다.

그리고 username과 서명 값을 웹사이트로 전송합니다. 마지막으로 웹사이트는 사용자가 가입할 때 등록한 공개키를 사용해서 "let me in" 메시지와 제출된 서명을 검증합니다.

서명이 유효하다면 사용자는 로그인됩니다.

우리는 방금 데이터베이스 유출 문제를 해결했습니다.

이제 웹사이트는 패스워드 해시 대신 공개키를 저장하면 됩니다. 공개키는 서명을 생성하는 데 사용할 수 없고, 오직 서명을 검증하는 데만 사용됩니다.

따라서 패스워드와 달리, 공개키는 유출되더라도 이를 이용해서 해당 웹사이트나 다른 웹사이트에 로그인할 수 없습니다.

하지만

피싱(phishing) 문제가 남았습니다. 사람들은 여전히 가짜 웹사이트에 서명 값을 제출할 수 있습니다.

사용자의 서명 값을 알아낸 공격자는 이를 사용해서 해당 사용자인 것처럼 진짜 웹사이트에 로그인할 수 있습니다.

피싱 문제를 해결해 봅시다.

피싱은 공격자가 사용자의 로그인 정보를 갈취하는 수법입니다. 피해자가 실수로 가짜 웹사이트에 로그인하면, 공격자는 그 정보를 실제 웹사이트에서 재사용합니다.

앞에서 소개한 로그인 방식은 모든 웹사이트가 "let me in"이라는 동일한 메시지를 사용해서 서명을 만들었기 때문에 피싱에 취약했습니다.

설계를 수정해 봅시다.

첫 번째로 할 일은 서명할 메시지를 바꾸는 것입니다. 서명할 메시지에 로그인할 웹사이트의 이름을 넣어 봅시다. 그리고 메시지를 JSON 형태로 바꿔 봅시다.

사용자가 로그인할 때 사용자의 컴퓨터는 사용자의 개인키를 사용해서 서명 작업을 실행합니다.

하지만 이제 "let me in" 메시지 대신 {"origin": "https://example.com"} 메시지를 사용합니다.

웹사이트는 생성된 서명에 대해 검증 작업을 실행해야 합니다.

검증 작업에는 메시지 입력이 필요하므로 사용자의 컴퓨터에서 서명 및 username과 함께 메시지를 전송하도록 합시다.

이제 사용자가 악성 링크를 클릭해서 exampl3.com(악의적인 피싱 웹사이트)에 로그인을 시도할 때 어떤 일이 일어나는지 생각해 봅시다.

사용자의 컴퓨터는 {"origin": "https://exampl3.com"}이라는 메시지에 서명합니다.

피싱 사이트가 이 서명을 갈취해서 진짜 웹사이트에 전달하면 진짜 웹사이트는 사용자의 서명이 다름(다른 origin를 기초로 만들어진 것임)을 인식하고 로그인을 거부합니다.

(컴퓨터는 사람과 달라서 URL에서 문자 하나만 바뀌어도 확실하게 감지할 수 있습니다.)

피싱 사이트는 메시지를 바꿀 수 없습니다.

메시지를 바꾸더라도 사용자의 개인키가 없기 때문에 유효한 서명을 새로 만들 수 없습니다.

이제

피싱 사이트 문제는 해결됐습니다.

하지만, 진짜 웹사이트에서 서명 값이 유출됐을 경우 유출된 서명 값이 사용자 로그인에 사용될 수 있다는 문제는 여전히 남아 있습니다.

패스워드 해시와 달리 서명 값은 저장할 필요가 없습니다. 하지만, 자바스크립트 인젝션 및 부주의한 로깅을 통해 서명 값이 유출될 위험은 있습니다.

우리는 피싱 사이트 문제 해결하기 위해 사이트마다 고유한 메시지를 사용했습니다.

이제 서명 값 유출 문제를 해결하기 위해 인증(authentication) 시도마다 고유한 메시지를 사용해 봅시다.

두 번째로 할 일은 사용자가 로그인을 시도할 때마다 서명할 메시지를 바꾸는 것입니다.

사용자가 로그인을 시도할 때마다 웹사이트에서 랜덤 챌런지(random challenge) 문자열을 전송해서 서명하게 합시다.

사용자가 로그인을 시도할 때마다 랜덤 챌런지 문자열이 바뀌도록 합시다.

이제 서명할 메시지는 다음과 같습니다.

{"origin": "https://example.com", "challenge": "8065afbaa4faee78123ad2061bc78df3"}.

이제 악성 JavaScript나 부주의한 로깅에 때문에 서명 값이 유출되더라도, 그 서명 값은 그 즉시 쓸모를 잃습니다.

인증(authentication)할 때마다 서명할 메시지가 달라지기 때문입니다.

여전히,

개인이 얼마나 많은 공개키를 갖게 할지, 그리고 그 공개키를 어디에 저장하게 할지 고민해야 합니다.

간단한 답은 한 사람이 하나의 공개 키를 갖고 모든 웹사이트와 앱에서 사용하는 것입니다.

하지만 이 방법은 명백한 문제가 있는데, 그 공개키가 그 사람에 대한 고유한 추적 값이 된다는 점입니다.

사람들은 웹사이트나 앱에서 추적되는 것을 원치 않습니다.

지금은 각 웹사이트나 앱이 저마다의 암호키 목록을 갖는다고 가정하겠습니다.

실제로는 이보다 더 복잡하지만, 이후 장에서 자세히 다루겠습니다.

패스워드와 달리 개인키는 사용 중 어디에도 전송되지 않습니다.

편의를 위해 전용 하드웨어(보통 USB로 연결)를 이용해서 개인키를 생성하고 보관한다고 가정하겠습니다.

이렇게 하면 보안성이 극대화됩니다. 개인키를 생성하고 보관하는 이런 하드웨어는 어느 정도의 물리적 공격에도 버티도록 설계돼 있습니다.

인증(authentication) 시스템의

어쩔 수 없는 한계도 생각해야 합니다.

디지털 환경에서 사람들은 항상 컴퓨터를 통해 행동합니다.

사용자 인증(authentication)을 말할 때, 인증을 통해 직접적으로 권한을 얻는 것은 해당 사용자의 컴퓨터입니다.

따라서 해당 컴퓨터가 공격자에 의해 제어된다면 인증 시스템은 무의미해집니다. 인증 문제를 해결한다고 모든 보안 문제가 해결되는 것이 아닙니다.

하지만, 많은 보안 문제가 인증 문제와 관련돼 있습니다. 그렇기 때문에 세상을 바로잡기 위해서는 더 나은 인증 시스템이 필요합니다.

이 글의 주제인 WebAuthn이 바로 그런 시스템입니다.

패스키는 안전합니다. 패스워드처럼 기밀한 정보(private key)가 절대 서버로 전달되지 않습니다.

패스키는 사용하기 쉽습니다. 지금도 애플, 구글, MS 등 플랫폼 업체들이 패스키 사용에 필요한 화면을 한 단계라도 더 줄이기 위해 (사용자 편의성을 높이기 위해) 애쓰고 있습니다.

패스키는 표준입니다. 어느 누구도 패스키 기술을 독점할 수 없도록 W3C가 WebAuthn 스펙을 관리합니다.

패스키를 통해 디지털 일상생활이 보다 더 안전해지기를 바랍니다.

(이상입니다.)