How Common Security Practices and Advice May Hinder Computer Security

아티클
08/24/2016

Security Watch암호와 신용 카드 - 제1부

Jesper M. Johansson

필자는 최근 미네소타 주립대학의 학보에 실릴 기사 인터뷰 요청을 받았습니다.학교 측에서는 당연히 성공한 동문의 이야기를 싣고 싶어했지만 적절한 인사를 찾지 못했던 걸까요. 미력한 저에게 넘어오게 되었습니다.인터뷰 진행자는 저의 업무 분야에 대해 물어 보았고 저는 몇 분에 걸쳐 보안

인프라 소프트웨어에 대한 설명을 하고 있었습니다.그러자 인터뷰를 진행하던 그녀가 "너무 복잡한 얘기 같아요!저한테 보안이라 하면 암호와 신용 카드만 떠오르는 걸요."라고 소리치는 것이었습니다.

저는 이러한 반응에 잠시 동안 생각하다가 그녀가 사실 매우 좋은 점을 지적해 주었다는 사실을 깨달았습니다.보안이라는 건 사실 암호와 신용 카드에 대한 것이 맞습니다.최소한 최종 사용자에게는 이 이야기가 그대로 해당됩니다.업계에 종사하는 보안 전문가들이 생각하는 보안이란 암호화 알고리즘입니다. 여기에는 Kerberos가 TLS 또는 NTLMv2보다 더 나은지, WS*의 이점은 무엇인지, 암호 해시를 솔트해야 하는지를 비롯하여 보안 전문가들이 논의하기 좋아하는 기타 심오한 모든 주제들이 포함됩니다.물론 이러한 전문가들은 최종 사용자에 비해 다양하고 심층적인 견해를 갖고 있습니다. 그러나 대체적으로 전문가들이 놓치고 있는 가장 근본적인 한 가지가 있다면서비스 제공 대상인 최종 사용자에게 있어 보안이란 암호와 신용 카드에 대한 것이라는 점입니다.

맞습니다. 보안 전문가들이 논쟁을 벌이기 좋아하는 심오한 문제도, 개발하기 좋아하는 새로운 기술도 사실 알고 보면 모두 최종 사용자의 데이터를 보호하기 위한 것입니다.하지만 보안 전문가들은 아직도 올바른 방향을 잡지 못하고 있는 것 같습니다.IT 세계의 보안 전문가들은 해당 고객들의 특정 요구 사항을 지원하기 위해 존재합니다. 이 요구 사항이란 바로 데이터를 안전하게 보존하는 것입니다.여기에는 물론 IT 자산을 안전하게 활용하는 것 역시 포함됩니다.이것은 정말 중요합니다.

필자는 이전 칼럼에서 바이러스 백신 프로그램을 실행하기 위해 컴퓨터를 구입하는 사용자는 하나도 없음을 지적한 바 있습니다.사용자는 온라인 뱅킹을 이용하고, 컴퓨터 게임을 즐기고, 전자 메일을 작성하고, 과제를 수행하고, 기타 중요한 업무를 수행하기 위해 컴퓨터를 구입합니다.이와 마찬가지로 회사의 경우에도 단순히 NTMLv2 구현을 위해 IT 보안 부서에 투자하지는 않습니다.회사에서 IT 보안 부서에 투자하는 이유는 조직의 자산을 보호하여 전체 사업부에서 해당 IT 리소스를 안전하게 사용하고 비즈니스 목표를 달성할 수 있도록 하기 위함입니다.

보안 전문가의 역할은 올바른 서비스를 제공하는 것입니다.

그렇다면 필자는 오늘날의 보안 전문가들이 정말로 훌륭한 "서비스"를 제공하고 있는지 질문을 던지고 싶습니다.보안 전문가들이 도움이 되기보다는 실제로 방해가 되고 있지는 않을까요?또한 입법 관련자들이나 규정자들이 보안 전문가들이 방해가 되고 있는 데 일조를 하고 있지는 않은가요?필자는 현재 적용되고 있는 모든 최신 기술이 실제로 최종 사용자에게 유용한지에 대해 의문을 가지고 있습니다.따라서 전 세계 IT 공급업체가 실제로 도움이 되기보다 해를 끼치는 몇몇 부분에 대해 알아보도록 하겠습니다.

보안 전문가들이 제공하는 대부분의 보안 권장 사항 및 많은 보안 기술이 실용적이지 않거나, 잘못되었거나, 납득하기 어렵거나, 이 세 가지가 한꺼번에 뭉뚱그려진 상태(대부분의 경우)인 것처럼 보이는 경우가 더러 있습니다.본 3부작 시리즈에서는 이러한 세 가지 잘못된 사항 중 한 가지 이상에 해당하는 권장 사항을 알려 주거나 기술을 배포하여 사용자에게 혼란을 야기한 사례에 대해 알아보려고 합니다.

실용성 없는 보안 권장 사항

보안 전문가들이 사용자를 혼란스럽게 하는 가장 주된 요인 중 하나는 바로 실용성 없는 보안 권장 사항을 제공하는 것입니다.여기에 보너스로, 보안 전문가가 이러한 권장 사항을 잘못 만들기도 합니다.그림 1에서는 보편적으로 제공되어 왔으며 오랜 사용을 거쳐 검증되고 이론적으로 문제없는 것처럼 보이지만 전혀 유용하지 않은 권장 사항을 보여 줍니다.

그림 1 실용성 없는 보안 권장 사항 (더 크게 보려면 이미지를 클릭하십시오.)

보유하고 있는 각 온라인 계정마다 다른 암호를 사용하라는 부분이 보이십니까?이런 권장 사항은 30년 전에나 통하던 얘기입니다.인터넷을 사용하는 사람들의 수가 몇백 명 정도에 불과하고 특별히 좋은 암호를 선택하는 사람이 없던 그런 시절 말입니다.안타깝게도 이러한 권장 사항은 계속 유지되고 되풀이되고 있습니다. 뿐만 아니라 이를 오늘날의 컴퓨터 사용 실태에 맞게 조정하려는 노력이 전혀 보이지 않고 있습니다.

현재 몇 개의 온라인 계정을 보유하고 계십니까?필자는 개인적으로 115개의 계정이 있으며 이 중에는 아무런 관리 없이 주고받은 계정도 몇 개 있습니다.그림 1의 권장 사항에 따르자면 필자는 115개의 암호를 만들어야 하고 그것도 매번 30일에서 60일마다 변경해야 합니다.바꿔 말하면 매일 2~4개의 암호를 변경해야 한다는 말이 되는 것입니다.수학적으로 설명하자면일 년에 690~1380개의 암호를 사용하는 꼴이 됩니다.

이러한 권장 사항을 제공하는 일부 사이트의 기술 담당자라면 매일 4개씩 좋은 암호를 생각해 내고 115개의 현재 암호를 단기 메모리에 저장할 수도 있겠지만, 아마 99.99%의 일반 웹 서핑 사용자들은 이러한 작업을 절대로 감당할 수 없을 것입니다.

30~60일마다 모든 암호를 변경하도록 하는 권장 사항과 마찬가지로 모든 사이트마다 다른 암호를 사용하도록 하는 권장 사항도 순수하게 이론적인 관점으로 보면 사실상 일리가 있고 문제가 없습니다.그러나 실제로는 이러한 방법이 실용적이지 않습니다.오늘날 사용자들이 보유하고 있는 암호의 개수를 고려할 때 모든 암호를 종이에 기록해 두거나 특정 소프트웨어를 설치하여 도움을 받지 않는 한 이 권장 사항을 그대로 따를 수 없습니다.다음 사례로 넘어가 보겠습니다.

실용성 없고 잘못된 권장 사항

그림 2에 표시된 권장 사항은 세계적으로 규모가 가장 큰 은행의 웹 사이트에서 발췌한 것으로, 실용성이 없을 뿐만 아니라 잘못되기까지 한 사례입니다."Read our password advice(암호 권장 사항을 숙지해 주십시오.)"라는 제목 아래에는 "different passwords everywhere(모든 사이트마다 다른 암호 사용)"라는 문구가 있습니다.뿐만 아니라 "never write them down(절대 암호를 적어 두지 마십시오.)"이라는 권장 사항도 있습니다.

그림 2 실용성 없고 잘못된 권장 사항 (더 크게 보려면 이미지를 클릭하십시오.)

자, 이제 필자에게는 115개의 암호가 있으며, 매일 4개의 암호를 새로 만들어야 하고, 이것을 따로 적어 놓아서도 안 됩니다.잠시 필자는 암호를 다 기억하지 못하는 자신이 바보라고 느껴졌습니다.그러나 다른 사람도 이와 마찬가지라는 점을 깨달았습니다.사람은 115개의 암호를 쉽게 기억해낼 수가 없습니다.우리는 정보를 7개의 덩어리로 기억하고 처리할 수 있습니다. 이것이 인간의 프로그래밍 방식이기 때문이지요.인터넷에서 찾을 수 있는 대부분의 암호 권장 사항에 따르면 인간의 처리 능력으로는 암호를 한 개만 사용하는 경우에도 사실상 부족하다는 결론이 나옵니다. 자세한 내용은 "The Magical Number Seven, Plus or Minus Two:Some Limits on Our Capacity for Processing Information"(George A. Miller 지음, musanim.com/miller1956에서 확인할 수 있음)을 참조하십시오.

매우 안타깝게도 보안 업계에서는 암호에 대한 권장 사항을 통해 일반적으로 사용자를 잘못된 방향으로 이끌고 있습니다.보안 전문가들이 사용자에게 모든 사이트마다 다른 암호를 사용해야 한다고 권장할 경우에는 사용자에게 이러한 암호를 기록하고 안전한 다른 곳에 보관하는 방법에 대해서도 알려 주어야만 합니다.사용자는 암호를 종이에 직접 적어 두거나, 안전한 문서에 기록해 두거나, PasswordSafe(sourceforge.net/projects/passwordsafe)와 같은 전문 도구를 사용하여 보관해야 합니다.보안 전문가들도 모두 암호를 기록해 두거나 모든 사이트에서 동일한 암호를 사용하고 있는 것이 현실입니다.사실 최근 설문 조사에 따르면 88%의 사용자가 인증이 필요한 모든 시스템에서 동일한 암호를 사용하고 있다는 결과가 나왔습니다(msnbc.msn.com/id/24162478 참조).

암호를 적어 두지 말라는 권장 사항이 이러한 추세에 영향을 미치는 분명한 요인입니다.보안 전문가들이 사용자에게 알려야 할 사항은 암호 및 기타 중요한 데이터를 효율적으로 관리하는 방법이지 이러한 정보를 아예 관리하지 말라는 것이 아닙니다.사용자가 정보를 관리할 수 있게 되면 자격 증명이 손상되는 경우도 매우 적어질 것입니다.

납득하기 어려운 권장 사항

처음 소개한 두 개의 그림에서는 6, 70년대 및 80년대에나 통하던 낡은 방법이 반복적으로 사용되고 있음을 보여 주었습니다. 그 당시는 주요 사용자들이 온라인이나 웹 기반 서비스를 사용하지 않는 시대였지요.그때까지만 해도 이러한 권장 사항이 일반적으로 현명한 방식으로 받아들여졌기 때문에 이에 대해 큰 불평을 하는 사람은 없었습니다.

그러나 이러한 권장 사항은 사용자에게 혼란을 주며 어딘가에 암호를 저장해 두는 것에 대해 일말의 죄책감마저 들게 합니다.보안 전문가들이 이런 권장 사항을 제공하는 것은 사용자의 편의를 도모하는 것이 아니라 오히려 해를 끼치는 것입니다.사용자의 보안을 관리하는 방법을 찾아내는 것은 사용자의 몫이 아닙니다.그것은 바로 보안 전문가에게 달린 문제입니다.보안 전문가는 사용자가 보유한 모든 온라인 계정을 관리할 수 있는 적절한 해법을 찾아내야 합니다.그러나 대부분의 지침이 이러한 구시대적인 권장 사항을 되풀이하는 것이기 때문에 사용자들은 스티커 메모나 스프레드시트에 다량의 암호를 기록하여 관리하는 성가신 방법에 의존하고 있습니다.

암호는 하나의 인증 메커니즘으로서 많은 것을 제공합니다.그러나 암호의 가장 주된 문제는 사용자가 암호를 잊어버릴 수 있다는 점입니다.사람의 자연적 한계를 해결하려는 노력 대신 IT 업계에서는 암호를 바꾸거나 더 악화시키는 방법인 암호를 늘리기 위한 모든 종류의 새로운 메커니즘을 지속적으로 개발하고 있습니다.이러한 방법은 사용자를 더욱 혼란스럽게 할 뿐입니다.

필자는 지난 번 어느 금융 서비스 사이트에 방문했다가 로그온 화면에 사용자 이름 텍스트 상자만 덩그러니 표시된 것을 보고 놀라움을 금치 못했습니다(그림 3 참조).

그림 3 암호는 어디에 입력해야 할까요?

처음에는 웹 사이트에 악성 코드가 심어져 있는 줄 알았습니다.그리고 재빨리 사이트를 확인해 본 결과 제대로 된 사이트가 맞다는 걸 깨달았습니다. 사이트에서 인증서를 제공했으므로 간단히 확인할 수 있었지요.문제는 사람들이 사이트에 로그인할 때 사용자 이름과 암호를 입력할 수 있는 두 텍스트 필드가 함께 표시되는 화면에 익숙해져 있다는 것입니다.수년간 이런 공통적인 워크플로가 사용되어 왔습니다.그런데 어느날 갑자기 사용자 이름 하나만 물어보는 사이트가 있다고 생각해 보십시오. 순간 잠시 망설이게 될 것입니다.이 사이트의 경우 나중에 알고 보니 해당 서비스 업체에서 피싱 공격을 방지하기 위해 사진을 사용하여 사용자에게 사이트를 확인시키는 기술을 구현했던 것으로 밝혀졌습니다.이 기술의 취지에 따라 사용자 이름을 입력하면 그림 4와 같이 확인을 위한 사진이 사이트 화면에 나타납니다.

그림 4 최근 일부 사이트의 경우 사용자에게 사이트를 인증하기 위해 이미지를 사용함(더 크게 보려면 이미지를 클릭하십시오.)

이 이론은 사용자가 어떤 사이트에 어떤 이미지가 표시되는지 알고 있다는 것을 전제로 합니다.만약 올바른 이미지가 표시되지 않을 경우 사이트가 위조된 것인지 확인할 수 있습니다.이 방식은 그 자체만 보면 일리가 있는 개념입니다.사용자가 어떤 사이트에 어떤 이미지가 나오는지 알고 있다는 가정을 전제로 한다면 이 전략은 꽤나 훌륭하다고 할 수 있습니다.

물론 눈치 빠른 독자 여러분께서는 그림 4의 초록색 주소 표시줄을 눈여겨보셨을 겁니다.이것은 이 사이트가 SSL 및 EV(확장 유효성) 인증서를 사용하는 사이트임을 나타내며 따라서 주소 표시줄이 초록색으로 표시되는 것입니다.이는 곧 이미지를 사용하여 사이트를 확인한다는 대전제가 더 이상 특별한 가치가 없음을 의미하기도 합니다.오히려 이미지로 인해 일부 최종 사용자에게 혼란을 가중시킬 수도 있습니다.이 사이트는 이미 사용자에게 확인이 된 상태입니다. 회사 이름, 웹 사이트 주소, 신뢰할 수 있는 발급자 이름이 포함된 인증서를 제공하고 있기 때문입니다.게다가 주소 표시줄이 초록색으로 표시된다는 사실은 이 회사가 EV 인증서를 위해 3배 이상의 비용이 드는 별도의 단계를 수행했음을 알려 줍니다.

게다가 사진 역시 조작될 수 있습니다.사용자가 본인의 고유 사진을 제출할 수 있는 경우 공격자는 여러 가지 방법을 통해 어떤 이미지가 사용되는지 알아낼 수 있습니다.또한 해당 사용자가 모든 사이트에서 같은 사진을 사용할 가능성도 매우 큽니다. 이 경우 모든 공격자는 사용자가 관심 있어할 만한 콘텐츠가 포함된 사이트를 만든 후 - 이 예제는 스스로 생각해 보도록 할 것입니다. - 사용자에게 사이트 확인에 사용할 사진을 요청합니다.사용자가 모든 사이트에서 동일한 사진을 사용하는 경우 이 새로 만든 사이트는 사용자가 은행 등의 사이트에서 사용하는 이미지에 액세스하게 됩니다.

일부 사이트에서는 사용자에게 사용자 고유의 이미지를 선택하도록 하지만, 다른 사이트에서는 대중 사진 라이브러리를 사용하기도 합니다.예를 들어 그림 4에 표시된 사이트의 경우에는 선택할 수 있는 318개의 대중 사진이 있습니다.사용자가 자신의 고유 사진을 제출할 수 없는 사이트에서는 앞서 이야기한 수법이 통하지 않습니다. 그러나 사용자가 고유 이미지를 선택할 수 없다면 자주 방문하지 않는 사이트의 경우 그 사이트에 어떤 사진을 사용했는지 잊어버릴 수가 있습니다.필자는 솔직히 그림 4에 있는 사이트에 어떤 사진을 사용했는지 전혀 기억이 나지 않습니다. 스크린샷에 보이는 저 사진이 아닌 것만은 분명하지만 말입니다.

이러한 이미지 기반 사이트 인증의 문제점은 공격자가 318개의 사진 중 아무 사진이나 보여 주거나 Flickr에서 무작위로 사진을 선택할 수 있으므로 많은 사용자들이 막연히 이러한 이미지를 맞는 것으로 생각할 수 있다는 점입니다.많은 사람들이 어떤 사이트에 어떤 사진을 사용했는지와 같은 사항을 모두 기억한다면 오늘날의 피싱이나 보안 관련 문제는 일어나지도 않았을 것입니다.

그렇다면 이미 인증서를 통해 인증된 사이트에서 사진을 사용하여 사용자에게 사이트를 인증하는 이유는 무엇일까요?간단하게 인증서만 사용하고 사용자에게 이러한 인증서의 유효성 검사 방법을 알려 주는 것만으론 안 되는 걸까요?인증서는 그 자체로 이미 해당 사이트의 정체성을 사용자에게 검증해 주는 역할을 하니까요.

인증서를 받는 프로세스는 사용자의 사이트 인증 이미지를 받는 프로세스보다 훨씬 안전합니다.인증서가 EV 인증서이고 Internet Explorer® 7 또는 Firefox 3을 사용하는 경우에는 브라우저의 주소 표시줄에 관련 인증서 정보도 강조 표시됩니다.그러나 아쉽게도 이러한 강조 표시 기능은 고가의 EV 인증서에서만 작동합니다.

이미지 기반 사이트 인증의 보이지 않는 함정

사진 인증 기술은 여러 가지 문제점을 안고 있습니다.우선 사이트에서 사용자 이름을 수집하는 것이 무척 쉽다는 점입니다.잘못된 사용자 이름을 입력할 경우 그림 4의 사이트에는 그림 5와 같은 메시지가 표시됩니다.비밀 이미지를 선택한 사용자에 해당하는 사용자 이름을 올바르게 입력하면 이 사용자의 비밀 이미지를 볼 수 있습니다.당연히 이러한 정보는 공격자가 사용자에 대한 정보를 수집하려고 할 때 매우 유용하게 사용될 것입니다.

그림 5 사용자 이름을 손쉽게 수집할 수 있는 이미지 인증 사이트

여기에 나온 방법들은 사실 보안상 효과적이지 않습니다.공격자는 위조 사이트에서 간단히 로그온 워크플로를 복제할 수 있습니다.위조 사이트에서는 사용자 이름을 요청하고 이를 실제 사이트에 전달합니다.보다 멋진 디자인을 위해 실시간으로 양식을 업데이트할 수 있도록 클라이언트에 AJAX를 사용하기까지 하는 보안 관리자도 있습니다.더군다나 실제 사이트에서 로그온 양식에 대한 사이트 간 요청 위조 공격을 방지하지 않고 브라우저에서도 사이트 간 XML-HTTP 요청을 방지하지 않는 경우 AJAX 코드는 해당 요청을 실제 사이트에 바로 제출해 버릴 수도 있습니다.

이를 통해 비밀 사진이 표시되면 공격자가 데이터를 구문 분석하여 사진을 빼내온 다음 최종 사용자에게 표시합니다.다시 말하면 위조 로그인 사이트를 사용자에게 표시할 수 있는 공격자라면 누구나 사용자의 비밀 사진도 표시할 수 있습니다.결론적으로, 이미지 기반 사이트 인증은 아무런 득이 없다고 할 수 있습니다.이러한 사진은 사용자가 사이트에 대해 인증을 받기 전에 표시되므로 사용자 이름을 갖고 있거나 수집할 가능성이 있는 공격자도 해당 사진을 볼 수 있습니다.

양식을 제출하기 전에 인증서를 확인하는 법을 전혀 알지 못하는 사용자가 있다고 가정할 경우(이는 이미지 기반 사이트 인증 사용 자체가 이와 동일한 가정을 기반으로 한다고 간주할 때 매우 안전한 가정임), 이 사용자의 사용자 이름을 수집하는 것은 매우 간단합니다.또한 많은 이미지 기반 사이트 인증 스키마는 유효한 사용자 이름과 유효하지 않은 사용자 이름에 각각 다르게 응답하므로 사용자 이름을 수집하기가 쉽습니다.공격자는 공격을 시작하기도 전에 대역 외 방식으로 사용자 이름을 수집할 수 있습니다.

결국에 사용자들 중에는 보안이 강화되었다고 생각하는 사람도 있지만 더 혼란스러워하는 사람도 있습니다.이미지 기반 사이트 인증을 구현하는 데 막대한 비용을 들였지만 최종 사용자가 위조 웹 사이트에 자격 증명을 제출하도록 유인하는 악의적인 사용자를 막는 데는 별다른 도움이 되지 못했습니다.

이번 호 Security Watch는 여기서 마치도록 하겠습니다.다음 달에 연재되는 이번 시리즈의 제2부에서는 잘못된 보안 관행 및 바람직하지 않은 인증 구현 방식에 대한 사례를 추가로 더 알아보겠습니다.

Jesper M. Johansson은 보안 소프트웨어 분야의 소프트웨어 설계자이며 TechNet Magazine의 객원 편집자로서,MIS 분야 박사 학위를 취득했고 보안 분야에서 20년 이상의 경력을 보유하고 있으며 엔터프라이즈 보안 분야의 Microsoft MVP입니다.최근 저서로는 Windows Server 2008 Security Resource Kit가 있습니다.

목차

추가 리소스