01. 전통적 패스워드의 한계와 패스워드리스의 등장

1) 전통적 패스워드 방식의 위험성

사용자가 웹사이트, 애플리케이션, 네트워크 등 다양한 플랫폼에서 사용자는 자신의 신원(Identification)을 확인하기 위한 목적으로 고유한 문자열 조합의 동일여부는 확인하는데 사용되는 패스워드는 오랜 기간동안 사용자 인증의 핵심요소로 사용되었다. 패스워드 기반의 인증시스템은 사용자만 패스워드를 알고 있기 때문에 가장 간단한 신원인증 방식으로 사용되어 왔으나 최근에는 이와 같은 전통적인 패스워드(Traditional Password)에서 다양한 문제점이 제기되면서 새로운 사용자 인증방식의 필요성이 대두되고 있다.

Bitwarden에서 진행한 World Password Day 2023 PUBLIC조사에 따르면 국내외에서 발생한 보안 사고의 80%가 패스워드 관리 미흡으로 인해 발생되었으며, ‘password’, ‘1234567’, ‘admin’등 기본 패스워드나 알려져 있는 패스워드가 문제로 지목되었다. 2023년 12월 말에는 중국 해커가 국내의 IP카메라를 해킹해서 개인 사생활을 침해 할 수 있는 4,500개의 영상을 텔레그램을 통해 유포한 정황이 확인되었다. 애완동물이나 아기 관찰 용도 등으로 설치된 홈 CCTV를 포함하여 각종 IoT기기나 무선 라우터 등을 제품 출시 때 설정된 패스워드가 그대로 사용되면서 이와 같은 문제가 발생되는 것이다.

디지털 환경이 확산되면서 사용자가 사용하는 플랫폼이 증가됨에 따라 사용자는 플랫폼이 요구하는 패스워드 복잡도 기준에 맞춰서 다수의 패스워드를 관리해야 하는 문제에 봉착했다. 플랫폼에서는 8자에서 10자 이상의 최소 길이나 대소문자, 특수문자 등을 조합한 패스워드 생성을 요구하기 때문에 안전을 목적으로 요구되는 패스워드 복잡도가 오히려 다수의 플랫폼을 사용해야 하는 사용자들에게는 부담이 되면서 동일한 패스워드를 다수의 플랫폼에 재사용하거나 패스워드를 별도로 저장해서 관리하면서 새로운 보안 취약점으로 작용하고 있다.

패스워드 기반의 인증방식은 패스워드를 추측해서 로그인을 시도하는 공격 기법(Password Guessing Attack)을 통해서 사용자가 기억하기 쉬운 패스워드를 이용해서 공격하기 때문에 전통적인 패스워드 방식에서는 꾸준히 발생할 수 밖에 없는 공격이다.

[그림 1]과 같이 1개에서 15개 사이의 사이트에서 84%가 기존의 패스워드를 다시 사용하고 있으며, 가장 높은 수치인 31%의 사용자는 5개에서 10개 사이의 사이트에서 패스워드 재사용을 하고 있는 것으로 나타났다. 패스워드를 재사용하지 않는 사용자 비율이 전체 16%밖에 되지 않는 것으로 미루어 상당수의 사용자는 다수의 사이트에서 동일한 패스워드를 사용함에 따라 패스워드를 통해 사용자 인증을 할 수 있는 보안적 효과가 낮아질 수 밖에 없다.

특히 패스워드 재사용의 범주가 개인 서비스에만 국한된 것이 아니라 비즈니스 목적의 계정이나 업무 시스템에도 동일하게 반영되면서 패스워드 재사용으로 인한 문제가 비단 개인의 문제가 아니라는 것을 알 수 있다. 이러한 패스워드 재사용을 이용한 대표적인 공격방식이 바로 크리덴셜 스터핑(Credential Stuffing)이다. 크리덴셜 스터핑은 기존에 유출된 패스워드를 이용해서 다른 사이트에 대입하는 공격방식으로 동일한 패스워드를 다수 사용하는 사용자에게 효과적인 공격방식이다. 2023년 국내에서도 인터파크, 지마켓, 스타벅스 등에서 크리덴셜 스터핑 공격으로 인해 상품권 도용 및 충전금 도용 등의 금전적 피해가 발생되었다.

이와 같은 패스워드 관련 보안위협들을 대응하기 위한 방안으로 패스워드 관리 소프트웨어 도입이나 2단계 인증(2FA) 및 다중인증(MFA)등을 통한 추가 보안 수단이 도입되고 있으나 패스워드를 이용한 사용자 인증 방식의 근본적인 문제를 해결해주지는 못하고 있다. 최근에는 전통적인 패스워드 인증방식의 한계를 해소하고자 패스워드없이 사용자 인증을 할 수 있는 패스워드리스 인증방식이 부각됨에 따라 이번 호에서는 전통적인 패스워드 기반의 인증방식과 패스워드리스 기반의 인증방식을 비교해보고 패스워드리스 방식을 이용하기 위한 기술적 방안 및 고려사항을 알아보고자 한다.

2) 전통적 패스워드와 패스워드리스 비교

상당수의 시스템과 플랫폼은 사용자 인증방식으로 전통적인 패스워드 기반을 제공하고 있기 때문에 패스워드 설정을 위한 설정이 용이하고 초기 도입비용이 낮다. 그러나 앞서 언급한 바와 같이 피싱(Phishing), 무차별 대입 공격(Brute Force), SQL 인젝션(Injection), 레인보우 테이블 공격(Rainbow table attack) 등 패스워드를 탈취하기 위한 다양한 공격이 시도되고 있으며, 주기적인 패스워드 변경 및 복잡성을 유지해야 하기 때문에 관리적인 한계가 발생하게 된다. 특히 패스워드를 재사용하는 문제는 재사용된 패스워드의 최초 유출 경로를 확인하기 어렵기 때문에 패스워드 인증 환경에서 가장 문제가 되는 요소라고 할 수 있다.

패스워드리스 방식은 용어 그대로 패스워드를 사용하지 않기 때문에 피싱 공격이나 패스워드 유출 위험은 없지만, 패스워드를 대체하는 생체인식이나 인증 앱, 푸시 알람, 일회용 코드 등으로 인해 해당 인증 수단에서 장애가 발생하는 경우 접근제한 및 추가적인 보안위협이 발생될 소지가 있다. 물론 사용자 인증 과정에서 사용자가 패스워드를 직접 입력하는 행위가 사라지기 때문에 SQL Injection이나 레인보우 테이블 공격 등에서 안전한 뿐만 아니라, 사용자에게 편리하고 빠른 인증 환경을 제공하고 패스워드 관리가 불필요하기 때문에 관리적인 편의성을 제공할 수 있다.

하지만 패스워드 인증방식과 달리 패스워드리스 인증방식을 위한 초기 인프라 구축비용이 높고, 새로운 인증수단을 위한 사용자 교육이나 시스템 전환비용이 추가로 발생할 수 있다. 또한 모든 시스템이 패스워드리스 인증방식을 지원하지 않을 수 있기 때문에 시스템 간의 호환성 문제가 대두될 수 있다. 다양한 디바이스 지원으로 인한 기술적인 복잡성과 하나의 인증이나 푸시 알림, 일회용 코드의 통신 채널 보안 등은 패스워드로 인한 문제보다 더 큰 보안위협이 될 수도 있기 때문에 인증방식에 따른 제약사항과 보안이슈를 고려해야 한다.

02. 패스워드리스 인증 방식

1) 패스워드리스 인증 유형

사용자 인증(User Authentication)은 사용자가 주장하는 신원을 검증하기 위해 지식 기반, 행위 기반, 소유 기반, 존재 기반 등 다양한 기법을 사용하는 과정을 말한다. 사용자 인증 유형 중 소유 기반, 존재 기반은 패스워드리스 인증 체계를 활용할 때 주로 사용하는 유형이다.

소유 기반 인증은 보통 사용자를 등록할 때 비대칭 암호화 알고리즘(예: RSA, ECC 등)을 사용하여 키 쌍을 생성하며 클라이언트 측에 개인키, 서버 측에 공개키를 저장한다. 인증요청 발생 시 서버에서 챌린지 키를 생성하여 클라이언트에게 전송한다. 클라이언트는 해당 키를 개인키로 서명하여 서버로 전송하고, 서버는 서명된 키를 공개키로 검증하여 인증을 완료한다. 클라이언트가 개인키로 챌린지 키를 서명하는 단계에서 소유 기반이나 존재 기반 매체로 클라이언트를 확인하게 된다.

패스워드를 사용하지 않고 인증을 수행하기 때문에 OAuth 인증이 패스워드리스 기법의 일종이라고 생각하는 경우가 있지만 결론적으로 두 방식은 다르다.

OAuth는 사용자가 다른 서비스에서 인증된 상태를 활용하여 안전하게 권한을 부여 받는 방법이고, 패스워드리스 인증은 비밀번호 대신 다른 형태의 인증 수단을 사용하는 방법이다. 따라서, OAuth 자체는 패스워드리스 인증의 범주에 속하지 않는다. 물론, OAuth 제공자를 통해 로그인을 수행할 경우 서비스 사용자 입장에선 패스워드 없는 로그인을 했다고 생각할 수 있지만, OAuth 제공자에게 사용자 인증 과정을 전가한 것이므로 또다른 위협이 존재할 수 있다.

패스워드리스를 구현하기 위해선 제 3의 인증자가 필요하다. 제 3의 인증자는 보통 전용 인증 어플리케이션, OTP Authenticator, Email 등을 사용한다. 이 중 전용 인증 어플리케이션은 [그림2]와 같이 Key-Pair를 생성 해 어플리케이션 로컬 데이터베이스에 개인키를 저장하는 형태라고 볼 수 있다. 인증요청 시 Push 알림이 발생하며 Face ID, 지문 인식 등의 추가인증을 거치고 개인키를 조회하여 Challenge Response를 전달한다. 해당 형태는 별도의 인증 어플리케이션 구현이 필요하기에 비대칭키를 사용한 로컬 인증 방식과 Email 인증 방식, OTP 인증 방식을 구현하여 세부내용을 분석해보겠다.

2) 패스워드리스 로컬 인증 방식 구현방법

① 회원가입

클라이언트에서 Key-Pair를 생성되고 저장되기 때문에, 서버가 개인 키를 처리하거나 저장할 필요가 없다. 이는 개인 키가 서버를 통해 유출될 위험을 감소시켜 더 나은 보안성을 제공한다.

[그림 4]는 Web Crypto API(window.crypto.subtle.generateKey)로 Key-Pair를 생성하는 함수를 구현한 로직이다. Web Crypto API는 대부분의 브라우저에서 지원되며 공개키를 안전하게 전달하기 위해선 HTTPS 사용이 필수적이다.

[그림 5]는 생성한 Key-Pair 중 공개키를 서버로 전달하는 함수이다. 개인키를 저장하는 과정은 생략되었지만 개인키를 저장할 때는 개인키를 신뢰할 수 있는 공간에 저장해야 한다. localStorage에 저장할 경우, Cross-Site Script에 의해 개인키가 탈취될 수 있다. [그림 6]에서 username, publickey를 DB에 저장하여 회원가입을 완료한다.

② 로그인

우선 [그림 8]의 3번 라인에서 서버로 Challenge Key를 요청한다. 이 후 input file과 같은 Element로 입력 받은 개인키 파일을 crypto 메소드로 import한다. 해당 개인키로 challenge에 서명한 결과인 signature를 서버의 /verify 경로로 전달해 검증 결과를 확인한다.

서버는 클라이언트에서 전달받은 username으로 DB를 조회해 사용자의 공개키를 확인한다. 해당 공개키로 전달받은 challenge를 변수를 클라이언트와 동일한 방식으로 signature를 생성한다. 16번 라인에서 두 개의 signature 값이 동일한지 검증하고 클라이언트에게 결과를 반환한다.

[그림 10]은 서버로부터 전달받은 Challenge를 개인키로 서명한 값을 다시 서버로 전송한다. 서버는 저장된 공개키로 서명 값을 검증하여 반환한다.

3) 패스워드리스 Email 인증 방식 구현방법

① 회원가입

Email 인증을 구현하기 위해 서버에서 관리해야 하는 정보는 회원의 Email 주소이므로 기존에 운영 중인 시스템에도 간단하게 구현이 가능하다는 장점이 있다.

② 로그인

클라이언트가 로그인(/send-verification-email)을 시도하면 토큰의 수명이 1시간인 인증 토큰을 발행해 메일로 전달한다. 2번 라인과 같이 인증 링크는 서버의 /verify-email로 앞서 생성한 토큰을 전달하는 것을 알 수 있다.

/verify-email API에서 token의 유효성을 검증하고 decode 된 값 중 Email 주소를 사용해 DB에서 해당하는 Email 주소를 사용하는 사용자를 찾아 로그인을 완료한다. 추가로 DB Schema를 설계할 때 username과 email을 unique로 설정하여 다른 사용자와 동일한 정보로 가입하여 인증 메일을 가로채는 취약점을 방지해야 한다.

클라이언트는 [그림 15]와 같이 링크를 클릭하면 서버로 token이 전송되는 메일을 받게 된다.

4) 패스워드리스 OTP 인증 방식 구현방법

① 회원가입

클라이언트는 먼저, 회원 정보를 서버(/register)로 전달해 QR 코드를 전달 받는다. Authenticator 애플리케이션을 통해 QR 코드를 스캔하게 되면 6자리의 숫자(OTP)가 생성된다. 해당 OTP를 입력하여 서버(/verify)로 전달한다.

서버는 register 경로로 회원 정보를 전달받으면 해당 정보를 DB에 저장하지 않고 임시 저장한다. 해당 정보 중 email을 통해 OTP Secret을 생성하고 해당 Secret을 임시 저장 및 클라이언트에게 전달한다. verify 경로에 OTP를 전달받으면 임시 저장해둔 Secret을 통해 서버도 OTP를 생성한다. 클라이언트와 서버의 OTP가 동일하면 회원 정보를 DB에 저장한다.

[그림 19]과 같이 otpauth 스킴으로 totp URL이 생성된다. qrcode 라이브러리로 data:image 스킴으로 변경하여 클라이언트에 전달하여 QR코드 이미지 형태로 접근할 수 있다.

[그림 20]과 같이 ① 과정을 통해 사용자 이름, Email 입력 후 회원가입을 진행한다. ② 회원가입 후 로그인을 하기 위해 Authenticator 앱을 이용해 QR코드를 등록한다. [그림 21]에 존재하는 OTP 확인 후 OTP 입력란에 해당 값을 입력하면 로그인이 가능하다.

② 로그인

로그인 시 username을 통해 DB에서 Secret을 조회한다. 그 후 앞선 OTP 검증과 마찬가지로 서버 측에서도 Secret을 통해 OTP를 생성하고 클라이언트에게 전달받은 OTP로 검증을 수행, 검증 결과를 서버로 반환한다.

04. 결론

지금까지 전통적인 패스워드 방식과 패스워드리스 방식의 사용자 인증에 대해서 살펴보았다. 패스워드 재사용으로 인한 크리덴셜 스터핑이나 패스워드 관리 이슈를 해결하고 사용자 편의성이 증대될 수 있는 패스워드리스는 새로운 인증방식으로 대두되고 있으나 전통적인 패스워드 방식을 대체하기 위해서는 다양한 고민이 필요하다.

운영 시스템의 사용 목적과 보안 수준에 따라 다양한 패스워드리스 방식이 제기되고 있으나, 인증자의 결함으로 인증 체계가 중단될 수 있기 때문에 다양한 인증 채널 구축이 필요하면서 운영 신뢰도가 높은 전통적인 패스워드 방식을 패스워드리스가 모두 대체하는 것은 어려운 일이다.

현재 패스워드리스 인증을 도입한 상당수의 애플리케이션이 기존의 패스워드 방식과 더불어 선택적인 요소로 패스워드리스를 사용하는 이유도 바로 이러한 문제를 우려한 것이라고 할 수 있다. 물론 패스워드리스 인증방식의 안전성이 높아지면 전통적인 패스워드 인증을 대체할 수 있을 것으로 보이나 그러기 위해서는 기술적인 안전성과 편의성, 호환성 등에 대한 연구가 필요할 것으로 보인다.

최근 사용자 인증 방식으로 뇌파, 홍채, 안면인식 등 존재기반의 인증방식이 보편화되면서 인증 기기의 신뢰도가 높아지고 민감 정보 활용에 대한 거부감이 낮아지면서 다양한 인증체계가 활용되고 있다. 패스워드리스 방식도 사용자가 인증과정을 인식하지 않고 다양한 편의성과 활용성을 제공할 수 있는 차세대 인증방식이기 때문에 현재 봉착하고 있는 문제들을 해결해 나간다면 다양한 분야에서 활용할 수 있을 것이라 기대해 본다.

05. 참고자료

1.https://bitwarden.com/resources/world-password-day/
2.https://www.npmjs.com/package/speakeasy