보안 기능은 늘었지만 설계는 20년 전 수준

서울여대 정보보호학과 강은성 교수님의 링크드인 포스팅입니다. 보안 기능은 계속 늘었지만, 보안 설계는 여전히 20년 전 수준이며 그 비용은 사용자에게 전가되고 있다는 지적입니다.

보안은 기능의 개수가 아니라 설계의 질이 중요하다는 것이고, 여전한 우리나라의 전형적인 “보안 체크리스트 충족” 중심 접근에 대한 냉정한 비판입니다;;

여전히 우리의 보안은 사용자에게 복잡한 비밀번호를 요구하고 반복인증과 이른바 CAPTCHA 부담을 전가하는 등 사용자 통제 중심 모델에 머물러 있습니다. 반면 글로벌 트렌드는 서버·플랫폼 중심 통제, 리스크 기반 인증(risk-based authentication), 보이지 않는 보안(invisible security)이라는 점에서 대비된다는 말씀입니다. 많은 걸 생각하게 하는 글입니다.

강은성 교수의 글

최근 한 사이트에 가입을 해야 했는데, 아직도 이런 사이트가 있나 싶어서 끄적여 봅니다. 꽤 유명한 사이트여서 겪으신 분들도 있으실 것 같습니다.

1. 비밀번호 길이가 최대 12자리

알고 보니 제가 입력한 비밀번호가 13자리였습니다. 5회 로그인 실패로 비번 재설정까지 하느라 시간 좀 들였습니다. 최대 로그인 실패 횟수 제한 기능을 구현할 정도라면 보안에 관심이 있는 사이트라는 건데, 비번 길이를 12자리로 제한한 이유는 무엇일까요?

비번을 hash해서 저장할 테니까 저장할 길이는 이보다 훨씬 길 것이므로 DB 테이블 문제는 아닐 것 같고, 결국 변수 길이가 최대 12자리라는 걸 의미일 텐데 말이지요. 다양한 플랫폼 지원, 구세대 개발의 유산 등 여러 이유가 있을 수는 있으나, 모두 옛날 옛날 옛적 얘기이긴 합니다.

2. 가입 시 비밀번호 입력 -> CAPTCHA 입력 -> OTP(PASS 또는 SMS)

아직 문자열 캡차를 입력하는 곳이 있더군요. CAPTCHA(Completely Automated Public Turing test to tell Computers and Humans Apart)는 사람과 컴퓨터를 구분하기 위한 수단, 그러니까 사람의 입력과 봇을 통한 자동화된 공격을 구분하기 위한 수단입니다.

사용자 인증 면에서는 비번과 OTP로 충분하고, 캡차를 쓰는 건 자동화된 공격으로 인한 서비스 시스템의 부하를 줄이기 위한 것이지요. 근본적으로는 사용자의 불편함을 담보로 사업자의 시스템 부하를 줄이는 방식인 셈입니다.

AI가 학습을 통해 캡차를 알아내니까, 더 어렵게 만들면서 이젠 사람이 맞추기 어려울 정도가 되어 사용자 편의성이 너무 떨어져서 많이 사라지고, 2010년대 중반에 이르러 이미 여러 이미지 중 호랑이를 골라라 하는 식의 이미지 reCAPTCHA 방식이 쓰이게 됩니다.

이미지 reCAPTCHA 역시 AI와 싸우면서 점점 더 복잡해 져서 이 또한 불편해 지고, 이제는 “봇이 아닙니다”라는 체크박스에 체크하도록 하면서 봇 여부를 판단하거나 아예 사용자와의 상호 작용 없이 백그라운드에서 판단하는 방식 등 사용성도 좋으면서 자동화된 공격을 탐지하는 다양한 방식이 나타나는 것 같습니다.

3. 비밀번호 -> CAPTCHA -> OTP까지 끝나야 비번이 틀렸다고 알려주네요.

이 또한 자동화된 공격을 완화하기 위한 방법이라는 건 알겠는데, 그러기 위해 사용자의 불편함을 최대화하는 방식이 사용된다는 점이 놀랍습니다. Usable security 개념이 1999년쯤에 나온 것으로 보고 있고, 문자열 캡차 사용이 줄어든 주 원인이 사용자의 불편함 때문인데, 문자열 캡차를 쓰면서 사용자의 불편함을 최대화하는 방식을 꿋꿋하게 유지하다니! 이래도 사업에 별 문제가 없는 것 같습니다. 저는 가입하는 데 10분 넘게 걸렸습니다.

할 일이 쌓여 있는데, 서비스 가입 시간보다 훨씬 더 긴 시간을 들여 이 글을 쓰게 된 원동력은 과연 무엇일까요?^^

갑자기 추워졌네요. 이러다 갑자기 4월이 가기 전에 여름 같은 더위가 올지도 모르겠다는 불길한 생각이 드는군요. 한 주 편안하게 지내시기 바랍니다.