인증

컴퓨터 한 대를 한 사람이 쓰던 시절에는 이 절차가 필요 없었습니다. 자리에 앉은 사람이 곧 그 컴퓨터의 주인이었으니 따로 물을 일이 없었습니다. 서비스가 웹으로 옮겨 가면서 사정이 달라졌습니다. 화면 너머의 상대는 보이지 않고, 같은 주소로 수천 명이 동시에 들어오며, 그 안에는 남의 문서를 열어 보려는 사람도 섞여 있습니다.

페이지덱도 초기에는 이 절차 없이 굴러갔습니다. 사내 문서를 모아 둔 도구 하나를 태오가 만들어 두고 팀 전체가 비밀번호 하나를 같이 썼습니다. 편했지만 대가가 있었습니다. 어느 날 회의록 하나가 통째로 지워졌는데 누가 지웠는지 아무도 알 수 없었습니다. 접속한 사람이 전부 같은 계정이었기 때문입니다.

인증은 이 문제를 사람마다 다른 증거를 요구하는 방식으로 풉니다. 들어오려는 쪽이 자기만 아는 것이나 자기만 가진 것을 내보이고, 서버가 그것을 미리 받아 둔 값과 맞춰 봅니다. 맞으면 그 뒤의 모든 행동에 이름이 붙습니다. 누가 지웠는지 알 수 있게 된 것이 이 절차가 가져온 첫 변화입니다.

인증은 등록·제시·대조·유지의 네 단계로 돌아갑니다. 사람이 겪는 것은 두 번째 단계뿐이고 나머지는 서버 쪽에서 벌어집니다.

1. 등록. 계정을 만들 때 나중에 대조할 값을 서버에 넣어 둡니다. 비밀번호는 적힌 그대로 저장하지 않고 해싱한 값으로 둡니다. 해싱은 되돌릴 수 없게 뭉개는 계산이라, 계정 정보가 통째로 새 나가도 거기 적힌 것은 비밀번호가 아니라 뭉갠 값입니다.
2. 제시. 로그인 화면에서 아이디와 비밀번호를 냅니다. 이 구간은 오가는 내용을 암호화하는 통로로만 보냅니다. 같은 카페 와이파이에 앉은 사람이 그대로 읽어 갈 수 있는 값이기 때문입니다.
3. 대조. 서버가 받은 값을 같은 방식으로 뭉개 저장된 값과 맞춰 봅니다. 여기서 실패 횟수를 함께 셉니다. 자동 프로그램은 초당 수백 번을 시도할 수 있어서, 다섯 번 연속 틀리면 잠그는 규칙 하나가 비밀번호 길이보다 크게 작동합니다.
4. 유지. 맞으면 서버가 증표를 하나 내줍니다. 요청마다 다시 로그인하지 않도록 브라우저가 이 증표를 들고 다니며 요청에 붙이고, 서버는 계정을 다시 조회하는 대신 증표만 확인합니다. 증표를 서명된 문자열 하나에 담는 규격이 JWT입니다.

네 단계 전체를 직접 만들지 않는 길도 있습니다. OAuth는 비밀번호를 넘기지 않고 권한만 빌려주는 표준으로, 구글 계정으로 로그인을 누르면 페이지덱이 받는 것은 구글 비밀번호가 아니라 이름과 메일 주소를 읽어도 된다는 허가증입니다. 비밀번호를 아예 보관하지 않으니 유출될 비밀번호도 없습니다.

사람마다 다른 것을 보여 주는 서비스라면 예외 없이 필요합니다. 고르는 것은 필요 여부가 아니라 세기입니다. 무료 플랜 사용자에게는 비밀번호 하나로 충분하지만, 관리자 화면처럼 한 계정이 뚫리면 전부 뚫리는 자리에는 다중 인증을 겁니다. 다중 인증은 아는 것에 더해 가진 것까지 요구하는 방식이라, 비밀번호가 새 나가도 휴대폰이 상대 손에 없으면 계정은 남습니다. 기업 고객은 다시 다른 것을 요구합니다. 싱글 사인온은 회사 계정으로 한 번 로그인하면 딸린 서비스를 다시 로그인하지 않고 쓰게 하는 방식이고, 그 회사 입장에서는 직원이 퇴사할 때 계정 하나만 막으면 되는 구조입니다.

한계는 두 군데입니다. 첫째, 인증은 누구인지까지만 답합니다. 그 사람이 지금 요청한 일을 해도 되는지는 인가가 따로 답합니다. 로그인한 사람이면 남의 문서도 열리는 화면은 인증이 없어서가 아니라 인증만 있어서 생깁니다.

둘째, 한 번 통과하면 그 뒤로는 증표를 믿는 구조입니다. 증표가 유효한 동안은 다시 묻지 않으니, 그것을 훔친 쪽은 비밀번호를 몰라도 들어옵니다. 그래서 중요한 동작 앞에서 한 번 더 묻거나 증표의 수명을 짧게 두고, 사내망 안이라는 이유로 확인을 건너뛰지 않는 제로 트러스트 쪽으로 기준이 옮겨 가는 중입니다.

"이 API 는 인증만 걸려 있고 인가 검사가 없어요. 로그인만 했으면 남의 문서도 열립니다."

문 앞에서 누구인지는 물었는데 그 사람 몫인지를 묻지 않았다는 지적입니다.

"기업 고객이 싱글 사인온을 요구합니다. 계정을 자기 회사 시스템에서 관리하겠다는 거예요."

계정 관리 권한을 고객사로 넘겨 달라는 요구이고, 대개 계약 조건에 들어갑니다.

"관리자 계정은 다중 인증 없이 못 들어오게 막았습니다."

권한이 큰 계정에만 확인 단계를 하나 더 붙였다는 보고입니다.

페이지덱이 인증 방식을 손본 것은 규원이 기업 고객 계약을 앞두고서였습니다. 고객사 보안 담당자가 보낸 질문지에는 직원 계정을 어떻게 관리하고 퇴사자 계정은 언제 막는지를 묻는 항목이 있었고, 당시 답은 사람이 손으로 막는다였습니다. 태오가 싱글 사인온을 붙이고 관리자 화면에 다중 인증을 걸기까지 6주가 걸렸습니다.

바뀐 것은 계정 관리만이 아니었습니다. 계정이 사람 단위로 정리되면서 누가 어떤 문서를 열었는지의 기록도 그대로 쓸 수 있는 자료가 됐습니다. 수아가 고객사에 보낸 답변에 첨부한 것도 정책 문서가 아니라 이 기록이었습니다.

비밀번호를 복잡하게 만들수록 안전해진다는 오해가 가장 흔합니다. 가입 화면마다 대문자와 특수문자를 섞으라고 요구하니 그것이 안전의 핵심처럼 보입니다. 하지만 계정이 털리는 주된 경로는 누가 비밀번호를 알아맞히는 쪽이 아니라 다른 서비스에서 새 나간 비밀번호를 그대로 가져와 넣어 보는 쪽입니다. 복잡도 규칙은 이 경로를 전혀 막지 못합니다. 오히려 규칙을 빡빡하게 걸수록 사람들은 규칙을 겨우 만족시키는 한 가지 조합을 만들어 모든 서비스에 돌려 씁니다. 그러면 어느 한 곳이 털린 날 나머지가 함께 열립니다.

인증을 로그인 화면 이야기로만 보는 것도 잦습니다. 사람이 직접 겪는 인증이 그것뿐이라 그렇습니다. 실제로는 사람이 없는 자리에서도 같은 절차가 돌아갑니다. 결제 대행사 서버가 페이지덱에 결과를 알려 줄 때도, 사내 스크립트가 데이터를 뽑아 갈 때도 상대가 누구인지를 먼저 확인합니다. 화면 쪽만 챙기고 이쪽을 비워 두면, 로그인 화면은 멀쩡한데 주소만 아는 사람이 데이터를 그대로 받아 가는 통로가 남습니다.