몇년전만 해도 웹 사이트 로그인은 아이디와 비밀번호만을 요구하는 곳이 대부분이었다. 그러나 요즘들어서 다양한 인증 방식을 사용하는 곳이 많아진 것 같다.

2FA

첫번째로는 기본 아이디 + 비밀번호 조합에 추가적인 인증을 붙인 경우이다. 이 경우는 다들 많이 봤을것이다. 주로 이메일이나 문자로 발송된 인증코드나 OTP를 입력하기로 요구 받는다

여기 까지는 서버 어딘가에 비밀번호를 저장해야 한다. 해싱이나 암호화가 되어있다 한들, 어쨋든 비밀번호를 저장 해야 한다.
아래 방식들은 시스템에 비밀번호를 저장하지 않는다. 대신, 인증의 책임을 외부에 돌린다.
필자는 이 방식을 “인증 책임을 미룬다(위임한다, 전가한다)” 라고 자주 말한다.
이것을 통해서 혹시나 서버가 해킹을 당하더라도 비밀번호 까지 해킹 되는것을 방지할 수 있다. 또한, 영세한 시스템의 경우에는 인증 시스템이 열악할 수 있다. 이것을 외부 시스템에 위임함으로서 인증의 책임에서 멀어질 수 있다.

비밀번호 대신 OTP 입력

사실 이 케이스 때문에 글을 쓰게 됐다. Defined.Net(Nebula)은 회원가입시 비밀번호를 묻지 않는다. 대신 OTP 등록 절차를 제공한다. 그러면 아래의 사진과 같이 로그인 시에 비밀번호 대신에 OTP 코드를 입력해야 한다.

장점과 단점, 이 방법을 적용시 유의해야할 점 (필자의 생각)

• OTP라는 특성상 “물리적인 기기”를 가지고 있어야 한다. 그러므로 자연스레 인증의 단계가 추가된다.
  * 기존에는 “알고 있는것”만 인증하는것에서 “소유하고 알고 있는것”으로 단계가 높아진다.
• 무차별 대입 공격 측면에서 비교적 안전하다.
  * 무차별 대입 공격은 일반적으로 아주 멘 땅에서 시작하진 않는다. 이미 어디서 털린 비밀번호를 무차별 대입한다. OTP를 사용하면 이러한 사전 지식을 무효화 할 수 있다.
• 2FA의 귀찮음을 해소할 수 있다.
  * 기존에는 비밀번호도 입력하고 OTP도 입력해야 했다. 하지만 이제는 OTP가 비밀번호의 역할을 하기 때문에 귀찮음이 줄어든다.
• OTP 초기화 기능을 제공해야 하기 때문에 “이메일 서비스”에 의존하는것은 어쩔 수 없다

비밀번호 대신 이메일 인증 코드

Cloudflare Zero-Trust의 Access에서 처음 발견한 방식이다. 로그인시에 “이메일 주소”를 입력해라고 한다. 그러면 이메일 주소로 인증 코드를 보내준다. 사용자는 이메일로 수신된 1회성 인증 코드를 입력하면 된다.

이 방식이 “인증 책임의 위임”과 딱 맞는 말일 것이다. 사용자가 이메일 서비스에 로그인 할 수 있으면 적격한 권한을 가지고 있다고 판단하는 방식이다. 사실 구글이나 네이버 같은 대형 사이트에서는 자체 앱을 통한 로그인 검증, 국외 IP 차단, 로그인 모니터링 등의 다양한 옵션을 제공하기 때문에 우리가 직접 인증을 하는것 보다는 안전할 것이다.

필자는 이메일 인증 코드 방식이 기존 비밀번호 방식의 상위 방식이라고 생각한다. 어짜피 대부분의 서비스는 이메일 서비스에 접근할 수 있으면 로그인이 가능하다. (“비밀번호 초기화”라는 수단도 있다) 그렇기 때문에, 사실 로그인 시스템을 들여다 보면 “인증의 원천”은 결국 이메일 시스템이다.

장점과 단점, 이 방법을 적용시 유의해야할 점 (필자의 생각)

• 한번씩 이메일이 수신되지 않을때가 있다. 이때 손쓸 방법없이 기다려야 한다.
  * 필자의 경우, Steam에서 이메일 인증코드가 1시간 뒤에나 날라온 경우가 있다. 1시간 동안이나 로그인이 불가한 경우가 오는 것이다.
• 이메일 전송 API에 의존이 생긴다. 왠만한 경우 이메일 전송 API 또는 전송 서버를 활용해야 한다. 문제는 이 시스템에 장애가 발생하면 로그인이 불가능 해 진다.
  * 그러므로, 단일 실패 지점에 대한 대비가 필요하다. (“인증 코드 재전송”을 클릭하면 백업 API를 이용해서 전송 한다던지)
• 이메일 전송 비용이 발생할 수 있다.
• 어짜피 이메일 서비스에 접근할 권한이 있으면 “비밀번호 찾기”를 통해서라도 로그인 할 수 있다. 그러므로, 보안에 대한 걱정은 덜해도 될 것 같다.

그와 유사한 방법들

OpenAuth (OAuth)를 사용하는 경우도 많다. 마찬가지로, 인증의 책임을 전가하는 방식이다. 왠만한 경우에서 OAuth는 계정 시스템에 추가적인 인증 플러그인과 같은 형식으로 붙는다.

이메일 인증 대신 문자 인증을 사용하는 경우도 봤다. 그러나, 이 경우는 문자 발송 비용이 수반 된다는 점에서 운영 비용이 많이 발생할 것이라 생각된다. 해외 서비스까지 구상중이라면 글로벌 SMS 전송 업체를 구해야 하기 때문에 일이 복잡해 질 수 있다.

대신, 이메일 발송과 달리 SMS는 거의 즉시 메세지가 수신되기 때문에 사용자가 기다리는 시간이 적을것이다. 또한 웬만한 사용자들은 이메일 서비스에 들어가는것 보다 SMS 보는것을 더 편해 하기 때문에 편의성도 좋을것 같다.

아무튼, 최근 동향은 비밀번호를 서버에 저장하여 직접 검증하는 대신에, 인증 책임을 전가하는 방식이 보이고 있다. OpenAuth, 이메일, 문자 또는 OTP 등 형태만 다를 뿐이지 결국 본질은 그러하다고 생각된다. 구상하고 있는 서비스에서도 ‘굳이 사용자의 비밀번호를 받아야 하나?’ 싶은 생각이 든다. 오히려 비밀번호를 저장하지 않음으로서 더욱 보안상 안전해 질 것 같은 생각도 든다.