사례로 보는 패스워드와 사용자 경험의 관계

패스워드는 현대 서비스에서 가장 많이 이용되고 있는 사용자 인증 도구입니다. 하지만 이와 동시에 서비스 이용에서 사용자를 가장 괴롭히고 있는 도구이기도 하죠.

패스워드에 대한 정책은 사용자 경험에 깊이 영향을 끼치기 때문에 꽤 중요하며, 아직 이렇다 할 규칙의 통일이 이루어지고 있지 않은 요소입니다. 오늘 기술 블로그에선 말도 많고 탈도 많은 여러 사이트의 패스워드 정책에 대해 다루어보도록 하겠습니다.

편한 게 좋은가? 불편한 게 좋은가?

일반적으로, 패스워드 규칙이 까다로우면 사용자 경험을 나쁘게 한다는 시선이 많으나 단순히 그렇게만 볼 수 있는 문제는 아니라고 생각합니다. 패스워드가 소위 “털리는” 케이스의 사용자 경험에 대한 고민은 이 주장에 별로 고려되고 있지 않기 때문이죠. 사실 그런 고민이 없다면 패스워드가 그냥 없는 것이 사용자 경험에 가장 좋을 것입니다. :(

이에 대한 논의가 어려운 이유는 근본적으로 사용자 인증 피해의 규모가 서비스 성격마다 모두 달라서 그 수준에 대해 일률적으로 쉽게 정의할 수 없기 때문입니다. 하지만 인증 피해가 서비스 디자인의 실수 때문에 발생한다면 그 책임을 전적으로 서비스 제공자가 져야 함은 분명합니다.

그러므로 작은 차이는 있더라도 현재 자신의 인증 시스템이 가져오는 편의성과 보안 수준은 잘 알아두는 것이 좋습니다.

너무 편한 사례: 블리자드 배틀넷

블리자드 배틀넷은 최근 디아블로 3 포럼에 남긴 하나의 답글로 많은 논란을 불러일으켰습니다. 배틀넷 로그인 시 패스워드가 case-sensitive 하지 않다는 버그를 신고하자, 그것이 버그가 아니라 원래 모든 블리자드 게임이 그러하다고 답변을 단 것입니다. 실제로 블리자드의 최신 배틀넷 접속은 어떤 게임이든 대소문자를 구분하지 않았습니다.

이것이 어떤 문제가 있는 것인지는 해당 포럼 글의 의견에 잘 정리되어있는데요. case-sensitive 하지 않게 인증이 가능하게 하면 무작위 대입법이 훨씬 빠르게 사용자 인증을 뚫기 때문입니다.

알파벳 10자로만 이루어진 패스워드를 뚫는다고 가정할 때, 무작위 대입법이 대입해야 할 패스워드 수는 case-sensitive 한 것과 아닌 것이 아래 숫자만큼 차이가 나게 됩니다.

• case-sensitive: 144,555,105,949,057,024
• case-insensitive: 3,656,158,440,062,976

무려 40배나 차이가 나고 있습니다.

물론 혹자는 이에 대해 단지 게임이기 때문에 패스워드가 상대적으로 덜 중요하고, 쉽게 접속하게 배려하는 것이 게임을 즐기는 사용자에겐 더 중요하다고 주장하기도 합니다. 하지만 제가 생각하기에는 더 현명한 방법이 있었을 것 같군요.

꽤 똑똑한 사례: Facebook

Facebook은 어쩌면 블리자드와 비슷한 유형의 고민을 해결하기 위해 꽤 똑똑한 방법을 사용하여 업계의 주목을 받았습니다.

Your Facebook Account has Three Passwords

Facebook은 사용자의 패스워드를 세 가지 유형으로 저장해놓습니다. 하나는 일반 패스워드, 두 번째는 대소문자를 뒤집어놓은 패스워드, 세 번째는 첫 번째 문자만 대문자인 패스워드입니다.

이러한 패스워드 시스템은 사용자들이 로그인 시 가장 많이 실패하는 유형에 한해서만 추가 패스워드를 제공하여, 사용자 경험과 보안 두 가지를 모두 잡기 위한 전략으로 보입니다. 딱 두 가지 패스워드만 추가로 제공하므로 무작위 대입법으로도 큰 차이가 나지 않으며, 대부분의 패스워드 입력 실수(Capslock을 켜놓은 경우, 모바일 브라우저에서 대문자로 패스워드를 시작한 경우)에 대응해주기 때문에 여러 서비스에도 일반적으로 적용할 수 있는 아이디어라고 생각합니다.

바보 같은 사례

다음은 미국의 어떤 사이트에서 규정하고 있는 패스워드 규칙입니다.

1. The password must be exactly 8 characters long.
2. It must contain at least one letter, one number, and one special character.
3. The only special characters allowed are: @ # $
4. A special character must not be located in the first or last position.
5. Two of the same characters sitting next to each other are considered to be a “set.” No “sets” are allowed. … 이하 생략

이 규칙의 아주 재미있는 점은 매우 복잡한 규칙을 규정하고 있으면서 1번 규칙은 패스워드를 8자로 고정하고 있다는 점입니다. 7개여도 안 되고, 9개여도 안 됩니다. 즉, 정확히 8자리에 대한 가능성만 대입해보면 되기 때문에 무작위 대입에도 쉽게 당할 수 있습니다. 거기에 쓸모없는 규칙을 너무 많이 넣고, 주기적으로 패스워드를 강제로 변경하며 이전 패스워드는 다시 쓰지도 못하게 해서 사용성 면에서도 최악의 패스워드 시스템을 가지고 있다고 볼 수 있습니다.

마무리하며

패스워드 인증 시스템은 정책에 따라 보안과 사용성에 꽤 중요한 영향력을 끼치며 아직 이렇다 할 합의가 부족한 상태입니다. 정책에 대해선 각자 정해나갈 부분이 많지만, 적어도 이번 글에선 어떤 것이 스마트하고, 어떤 것이 그렇지 않은지 알아보았습니다.

이번 패스워드 관련 사례 모음은 사실 무작위 대입에 한해서 관점을 정리하였지만, 패스워드 인증 시스템은 그보다 더욱 다양한 논의사항이 있습니다. (패스워드 수를 노출하는 것이 옳은가? 패스워드를 그냥 보여주는 것은 어떠한가?) 이에 대해 다음에 한 번 더 다루어보도록 하겠습니다.