패스워드 에 해당하는 글 : 1 개
Draco님의 tweet에서 보고는 구글링해서 들어가 본 Unu라는 사람의 블로그에서 씁쓸한 글 하나를 읽었다. 요약하자면, 루마니아에 사는 자칭 화이트 해커(ㅋㅋ)라는 Unu라는 사람이 nProtect 홈페이지를 해킹해서 사용자 정보를 볼 수 있었다고 광고한 일이다. 국내 뉴스에서는 화이트해커라고 하던데, 뭐, 말하자면 공격해서 취약점은 밝혀서 망신을 주지만, 빼낸 정보를 악용하지는 않는다는 뭐 그런 얘기다. 그렇다고 하니 믿을 수밖에. :) Unu라는 사람은 SQL injection을 이용해서 홈페이지를 뚫긴 했는데, 나의 눈을 이끈 부분은 그런 자세한 해킹 기법이 아니고, nprotect에서 사용자의 패스워드를 clear text로 보관하고 있었다는 사실이다. 웃기는 짬뽕이다. 서버 해킹 당한 거는 이러저러한 연유로 그렇게 될 수도 있다 치지만, 사용자 패스워드를 clear text로 보관한다는 건, 사이트의 설계 당시부터 애초에 잘못된 보안 개념을 가지고 있었으며, 아직까지도 고칠 여유가 없었거나, 고칠 능력이 없었거나, 아니면 그게 잘못된 것인지를 아예 모르고 있었다는 얘기다.

이게 왜 잘못된 거냐 하면... 코딩이 짜증나니 머리도 식힐 겸 친절한 썰을 하나 풀도록 하자.

아이디와 패스워드는 대표적인 개인 인증 방식에 사용된다. 아이디는 자신의 이름과 같은 것이어서 각각의 개인을 구분하는 정보이고, 패스워드는 그 개인만이 알고 있는 비밀 정보이다. 패스워드를 알고 있는지 여부를 살펴서 그 아이디의 주인이 맞는지를 확인한다. 이게 대충 수박 겉핥기 식으로 정의하는 인증이다.

사실 이것보다는 우리가 허고헌날 쓰는 자물쇠와 열쇠의 비유를 쓰는 것이 좋겠다. 우리가 자물쇠를 열쇠로 열 때, 그 자물쇠에 꼭 맞는 열쇠가 있어야만 한다. 다른 말로 하자면, 자물쇠는 자신과 꼭 맞는 열쇠만을 인식한다. 자물쇠를 아무나 열지 못하게 하려면, 우리는 열쇠를 잘 간수해야 한다. (사실 우리는 열쇠를 꽁꽁 숨겨 다니지도 않고, 누가 열쇠를 쳐다 본다고 해서 그 열쇠를 도둑맞았다고 호들갑을 떨지는 않는다. 그래도 사진기와 같은 아주 정확한 기억력을 가진 누군가가 열쇠를 쳐다보고, 머리 속에 사진을 찍어 두었다가 그것과 똑같은 열쇠를 만든다면 열쇠를 도둑 맞은 것과 똑같은 상황이 되긴 한다. 물론, 보통 사람들은 그런 기억력을 가지고 있지 않기 때문에 우리는 열쇠를 누가 쳐다보는 것에 둔감하고, 그럴 만도 하다.) 열쇠의 모양은 자물쇠와 열쇠 사이의 비밀정보이다. 문지기가 자물쇠 옆에 늘상 붙어 있다고 해도, 자물쇠만 봐서는 열쇠의 모양을 알 수가 없다. 첩보 영화에 나오듯이 밀랍 덩어리를 자물쇠 안에 넣어서 모양을 짜내지 않는다면 ;)

그림으로 그리자면 이런 식이다.
발로 그린 그림이지만, 왼쪽이 자물쇠 오른쪽이 열쇠라고 너그럽게 봐 주도록 한다. (열쇠가 더 커 보이는 건 착시현상이다. 어찌됐든, 열쇠를 자물쇠에 넣는 것이 더 큰일 같아 보이긴 하다. ^^ ) 문지기는 사용자가 열쇠를 자물쇠에 넣는 짧은 동안에는 열쇠를 슬쩍 관찰할 수 있다. 문지기의 눈이 고감도 카메라라면 이 순간 열쇠는 도둑맞은 것이나 다름 없지만, 우리는 문지기의 관찰력이 그리 높지 않다고 대충 가정한다. 이러한 방식과 유사한 것이 대부분의 ID/PW 방식의 인증들이다. 사이트는 사용자가 전송한 패스워드를 짧은 기간동안 clear text로 볼 수 있다. 사이트 관리자가 딴 생각을 품고 이 패스워드를 다른 곳에 기록해 놓는다면 (문지기의 카메라 같은 시각) 이 사용자의 패스워드는 그 관리자에게 노출된다. 그런데, 암묵적으로 우리는 관리자가 인증 과정에서 관찰한 패스워드를 따로 몰래 저장해 놓지는 않는다고 가정한다.

앞의 nprotect 같이 패스워드를 평문으로 저장하는 것은 아래 그림과 같이 표현할 수 있다.
이게 뭔가. 열쇠를 관찰하는 사람 말고도 자물쇠를 관찰하는 사람도 열쇠의 모양을 알 수 있다. 이 경우에는 문지기의 눈을 가려 놓거나, 자물쇠를 또 다른 것으로 감싸고 거기에 또 다른 자물쇠를 달거나 하지 않으면 열쇠를 만들 능력이 되는 모든 사람이 자물쇠를 열 수 있다. 이런 바보 같은 자물쇠를 만드는 사람은 없을 것이다.

통상적인 Unix 패스워드 시스템에서는 자물쇠를 일방향 함수로 만든다. 일방향 함수라는 것은 순방향으로는 계산이 쉽지만, 역방향으로는 계산이 어려운 함수이다. 일방향 함수가 아닌 함수의 예는 쉽게 이런 것을 들 수 있을 것이다. f(x) = x + a. -.-;; f(x) = y 일 때, y를 알면 x는 당장 알 수 있다. x = y - a의 관계가 있기 때문이다. (물론 함수 자체는 완전히 주어진다. 즉, a가 공개된다.) 그런데 일방향 함수는 f(x)가 완전히 주어져 있을 때에도 역방향 계산이 어려운 함수이다. 사용자의 패스워드는 x(열쇠)에 대응되고, 서버가 보관하고 있는 것은 패스워드의 일방향 함수값 y(자물쇠)에 대응된다. 열쇠(x)가 들어오면, 서버는 일방향 함수를 통과시켜서 일방향 함수값(y)을 구하고 저장하고 있는 일방향 함수값과 같은지 비교한다. 같으면 통과, 틀리면 실패이다. 보통 자물쇠와 같이 서버는 저장하고 있는 일방향 함수값(y, 즉 자물쇠)만 가지고는 패스워드(x, 즉 열쇠)를 알 수 없고, 사용자가 패스워드를 주었을 때 맞춰 볼 수만 있다. (물론, 이 때 서버는 사용자가 전달한 패스워드를 인증이 끝나면 폐기한다는 조건이 있어야 한다.)

또다른 잡담으로, 앞의 보통 자물쇠의 경우 기술이 좋아서 자물쇠 내부를 잘 들여다 볼 수 있는 사람들이 있다. 시중에 떠도는 금고털이들이 그렇다. 그건 자물쇠의 구조적인 한계 때문이기도 하고, 그림처럼 열쇠의 모양을 마음대로 만드는 것이 아니라 생각해 볼 수 있는 열쇠의 모양의 가지수에 한계가 있기 때문이기도 하다. 이 경우, 문지기는 이런 공격을 시도할 수 있다. 열쇠 하나를 만든다. 자물쇠에 맞춰본다. 안 맞으면 다른 열쇠를 만든다. 또 맞춰본다. 이런 걸 몇백만번쯤 하면 자물쇠에 맞는 열쇠를 만들 수 있을 것이다. 더구나, 열쇠/자물쇠의 규격이 문제가 있어서, 열쇠의 모양에 한계가 있다면 만들어야 하는 열쇠의 수는 줄어든다. 톱니가 4개 달린 열쇠에 톱니 하나당 높이의 단계가 10개 뿐이라면, 열쇠를 만개만 만들어보면 된다. 실제 ID/PW 인증의 경우에는 열쇠를 만드는 게 정말 아무것도 아니다. 만개의 열쇠를 만들어서 자물쇠와 맞춰보는 작업을 몇초~몇시간 안에 할 수 있다. 그러니, 패스워드를 그냥 숫자 키패드에서 몇개 찍어서 쓰는 사람들은 몇초 안에 깨질 수 있는 패스워드를 쓰고 있다는 뜻이 된다.

또또 다른 잡담으로, 인증 과정에서 열쇠를 슬쩍 훔쳐볼 수 있는 서버(또는 문지기)가 탐탁치 않을 경우에는 어떻게 하는가. 자물쇠와 열쇠의 예에서는 비교적 간단하다. 열쇠를 조심해서 꺼내고, 손으로 잘 감싼 후에 자물쇠와 열쇠를 잘 갈무리해서 열면 된다. 열고 나서도 손으로 잘 감싸서 주머니에 넣으면 된다. 그럼 ID/PW를 이용한 인증에서는? 사실 방법이 없다. 자물쇠와 문지기의 예에서는 자물쇠와 문지기가 별개의 객체인 것처럼 말을 했지만, 실제로는 그렇지가 않다. 굳이 비유하자면, 사용자가 열쇠를 문지기에게 주면, 실제 열쇠를 자물쇠에 맞춰보는 건 문지기가 한다. 문지기에게 줄 때까지 열쇠를 아무리 잘 갈무리해봤자 일단 문지기에게 주고 나면 문지기가 열쇠를 빼돌리지 않는다고 그냥 믿어야 한다.

이와 관련하여, 웹서버의 경우 https 통신을 하면 무조건 안전하다고 믿는 사람들이 있다. 뭐, 사실 안전도가 비약적으로 상승하는 것은 맞다. 앞의 비유에서는 사용자가 문지기의 바로 앞에서 열쇠를 꺼내 주는 것처럼 보이지만 그렇지가 않기 때문이다. 현실에서는 열쇠를 꺼내서 본을 뜨고 어쩌고 해서 열쇠의 (완전히 똑같은) 사본을 만든다. 그리고 속이 잘 비치는 편지 봉투에 넣고 우편함에 넣으면, 오토바이를 타고, 트럭을 타고, 기차나 비행기를 타고 문지기에게까지 배달된다. 그리고 문지기가 열쇠를 자물쇠에 맞춰본다. 그러니 배달 과정에 있는 수많은 사람들이나 또는 우편함 속에 몰래 숨어 있던 스파이가 열쇠를 빼돌릴 수 있다. https 통신을 하면 열쇠를 무지하게 튼튼한 봉투에 넣어서 전달하는 것과 같게 된다. 그러니, 걱정해야 하는 수많은 사람들은 나가 떨어지고 문지기만 남게 된다. 안전도는 비약적으로 상승한다. 하지만... 여전히 문지기는 남아 있다. ID/PW 방식을 사용하면 이건 어찌해 볼 수가 없는 문제이다. PKI 방식을 쓰는 수 밖에.


ps. 그림 그리는 게 제일 힘들었음. -.-;;
ps2. 왜 글이 점점 늘어나지 -.-;; 일하기 싫다는 증거.
ps3. 패스워드편 말고 다른 게 있을지는 며느리도 모름.

'Cryptography' 카테고리의 다른 글

KCDSA & EC-KCDSA + OpenSSL  (2) 2009.09.30
OpenSSL의 crypto library 뜯어보기 2  (0) 2007.04.24
OpenSSL의 crypto library 뜯어보기  (0) 2007.04.18
  
트랙백   |  댓글   |
 이전  1   다음 

최근댓글
fotowall :: ncloud RSS Feeds today :    yesterday :
total :