[282] 이글루스 스토킹하기 in far from Reality
이글루스의 User ID의 방식을 분석하신 글이 있어 그에 대한 간단한 이야기를 해볼까 합니다.
보통 예전에 멤버쉽 데이터 베이스를 설계할 때는 주민등록번호 또는 아이디를 Primary Key로 설정한 경우가 많았습니다. 그렇기 때문에 동일 주민등록번호에 대한 문제와, 아이디의 변경, 또는 기존 아이디를 갖고 있던 사용자가 탈퇴했을 때, 그 문제를 처리하기가 어려웠습니다.
첫번째 주민등록번호의 경우는, 주민등록번호가 같은 사람이 대한민국에 약 3% 가량 있기 때문에 어떤 경우든지 겹칠 수 있습니다. 그럴 경우에 두번째로 가입하는 동일 주민등록번호의 사용자를 다른 주민등록번호로 가상으로 설정해서 가입시켜야만 했습니다. 이 문제는 주민등록번호를 왜 요구하는가?에서 언급한바 있으며, 아직도 이것을 Primary Key로 삼는 경우가 많다고 합니다.
두번째 아이디의 경우는, 가입할 때 체크하기 때문에 단순합니다. 그러나 만약 이 사용자가 아이디를 변경한다면? 또는 탈퇴한다면? 이 경우 문제가 생깁니다. 만약 아이디를 변경한다면, 지금까지 사용했던 A라는 아이디로 썼던 게시물 등 그 사용자의 서비스 내에서의 권리가 모두 무시되는 문제가 발생했습니다. 또는 탈퇴했을 때도 마찬가지입니다. A라는 사용자가 탈퇴했을 때 다른 어떤 사용자도 A라는 아이디를 쓸 수 없었습니다. 실제로 하이텔이 그랬습니다.
그래서 새로운 대안(?)으로써 나온 것이 User Number를 할당해서 그것으로 모든 사용자를 컨트롤하는 것입니다. 사용자가 가입할 때 입력하는 아이디와 주민등록번호 모두 인증에만 사용할 뿐, 실제로 서비스 내부에서 그 사용자를 구분하는 Primary Key는 모두 User Number로 하는 것입니다.
이글루스도 마찬가지로 User ID는 별도로 두어 로그인 등 인증에 사용하고, User Nickname은 보여질 때 사용을 하고 있습니다. 그리고 그 유저를 구별하는 키로 User Number를 사용하고 있습니다. 그 유저 넘버의 방법은 Xnnnnnnnn(알파벳 a~z 또는 그 문자의 확장 + 7자리 고정 숫자)입니다.
이 방법은 위에서 말했던 두 가지 문제점, 즉 주민등록번호의 중복 문제와 아이디 변경 또는 탈퇴 때의 온라인 서비스 상에서의 사용자의 자산에 대한 권한 부여의 문제가 해결됩니다. 아이디를 어떻게 변경하던, 그 사람의 권한은 User Number를 키로 부여가 가능하기 때문입니다.
실제로 제가 전에 개발했던 서비스에서도 이와 유사한 방식을 사용했습니다. 그 방법은 1000~∞이었습니다. 무한히 사용자 계정이 생성될 수도 있으니까요.
그러나, 이 순차적으로 누적되는 User Number는 문제가 있을 수도 있습니다. 서비스의 URL을 등을 가로채서 User Number와 URL을 조합하여 다른 사용자의 권한을 가로챌 수 있는 행동을 사용자가 시도하기 때문입니다. 물론, 이런 모든 문제를 최대한 방지하는 서비스를 만드는 것이 바람직하겠습니다만, 그것이 100% 완전하기 역시 어렵습니다. 그것을 방지하기 위해서 다음같은 서비스는 그 User Number를 한번 더 암호화하는 방식을 쓰고 있습니다.
User Number를 하나의 암호키로 변환하여 멤버쉽 DB에 저장하고, 이것을 통해서 User를 구분하는 Primary Key로 이용하는 것이죠. 이렇게 할 경우 만에 하나 URL을 통한 크래킹이 시도되었을 때 그 사용자의 User Number를 무작위로 예측해서 뽑아내는 것은 불가능하게 됩니다(물론, 직접 HTML 코드에서 뽑아내는 것만은 막을 수 없습니다). 만약 이 방식이었다면, 우유차님이 찾아낸 방법으로 찾을 수는 없었을 것입니다.
이게 대체 무슨 문제냐? 라고 말씀하시겠지만, 사용자들은 다양한 방법으로 크래킹을 시도하고 의외로 아주 단순한 곳에서 문제가 생기기 쉽습니다. 일반적으로 들어올 수 없는 URL을 추측하고 시도해서 그것을 통해 다른 사용자의 권한을 탈취하려는 시도를 하는 사용자가 있기 때문입니다. 이것을 막는 원시적인 방법으로 frame 태그 등으로 막기도 하고 있습니다.
이글루스 역시 같은 문제점에 봉착해 있다고 봅니다. 현재는 유료 서비스 부분도 적고, 권한을 탈취하려는 시도 역시 적은 듯으로 보입니다만(물론 아닐 수도 있습니다), 언젠가 마주칠 부분이라 보이고 언젠가는 그에 대한 대책이 있어야겠죠. 다음처럼, User Number를 암호화하거나, 또는 크래킹에 대해서 권한 체크 등을 확실히 하거나. (paranoia님의 덧글을 보고 추가 설명으로 남깁니다. User Number의 암호화는 필수가 아니라 선택입니다. 반대로 크래킹에 대해 권한 체크를 확실히 하는 것은 필수입니다)
그리고 여담입니다만, a/b 등으로 나뉘는 것은 그것을 키로 멤버쉽의 DB가 논리적, 물리적으로 분산되어 있는 것이 아닐까 하는 추측입니다. 그냥 추측이고, 맞다고 해도 온네트에서 가르쳐 줄리도 만무하겠습니다~!
마지막으로.
저도 참 심심한가 봅니다~!
이글루스의 User ID의 방식을 분석하신 글이 있어 그에 대한 간단한 이야기를 해볼까 합니다.
보통 예전에 멤버쉽 데이터 베이스를 설계할 때는 주민등록번호 또는 아이디를 Primary Key로 설정한 경우가 많았습니다. 그렇기 때문에 동일 주민등록번호에 대한 문제와, 아이디의 변경, 또는 기존 아이디를 갖고 있던 사용자가 탈퇴했을 때, 그 문제를 처리하기가 어려웠습니다.
첫번째 주민등록번호의 경우는, 주민등록번호가 같은 사람이 대한민국에 약 3% 가량 있기 때문에 어떤 경우든지 겹칠 수 있습니다. 그럴 경우에 두번째로 가입하는 동일 주민등록번호의 사용자를 다른 주민등록번호로 가상으로 설정해서 가입시켜야만 했습니다. 이 문제는 주민등록번호를 왜 요구하는가?에서 언급한바 있으며, 아직도 이것을 Primary Key로 삼는 경우가 많다고 합니다.
두번째 아이디의 경우는, 가입할 때 체크하기 때문에 단순합니다. 그러나 만약 이 사용자가 아이디를 변경한다면? 또는 탈퇴한다면? 이 경우 문제가 생깁니다. 만약 아이디를 변경한다면, 지금까지 사용했던 A라는 아이디로 썼던 게시물 등 그 사용자의 서비스 내에서의 권리가 모두 무시되는 문제가 발생했습니다. 또는 탈퇴했을 때도 마찬가지입니다. A라는 사용자가 탈퇴했을 때 다른 어떤 사용자도 A라는 아이디를 쓸 수 없었습니다. 실제로 하이텔이 그랬습니다.
그래서 새로운 대안(?)으로써 나온 것이 User Number를 할당해서 그것으로 모든 사용자를 컨트롤하는 것입니다. 사용자가 가입할 때 입력하는 아이디와 주민등록번호 모두 인증에만 사용할 뿐, 실제로 서비스 내부에서 그 사용자를 구분하는 Primary Key는 모두 User Number로 하는 것입니다.
이글루스도 마찬가지로 User ID는 별도로 두어 로그인 등 인증에 사용하고, User Nickname은 보여질 때 사용을 하고 있습니다. 그리고 그 유저를 구별하는 키로 User Number를 사용하고 있습니다. 그 유저 넘버의 방법은 Xnnnnnnnn(알파벳 a~z 또는 그 문자의 확장 + 7자리 고정 숫자)입니다.
이 방법은 위에서 말했던 두 가지 문제점, 즉 주민등록번호의 중복 문제와 아이디 변경 또는 탈퇴 때의 온라인 서비스 상에서의 사용자의 자산에 대한 권한 부여의 문제가 해결됩니다. 아이디를 어떻게 변경하던, 그 사람의 권한은 User Number를 키로 부여가 가능하기 때문입니다.
실제로 제가 전에 개발했던 서비스에서도 이와 유사한 방식을 사용했습니다. 그 방법은 1000~∞이었습니다. 무한히 사용자 계정이 생성될 수도 있으니까요.
그러나, 이 순차적으로 누적되는 User Number는 문제가 있을 수도 있습니다. 서비스의 URL을 등을 가로채서 User Number와 URL을 조합하여 다른 사용자의 권한을 가로챌 수 있는 행동을 사용자가 시도하기 때문입니다. 물론, 이런 모든 문제를 최대한 방지하는 서비스를 만드는 것이 바람직하겠습니다만, 그것이 100% 완전하기 역시 어렵습니다. 그것을 방지하기 위해서 다음같은 서비스는 그 User Number를 한번 더 암호화하는 방식을 쓰고 있습니다.
User Number를 하나의 암호키로 변환하여 멤버쉽 DB에 저장하고, 이것을 통해서 User를 구분하는 Primary Key로 이용하는 것이죠. 이렇게 할 경우 만에 하나 URL을 통한 크래킹이 시도되었을 때 그 사용자의 User Number를 무작위로 예측해서 뽑아내는 것은 불가능하게 됩니다(물론, 직접 HTML 코드에서 뽑아내는 것만은 막을 수 없습니다). 만약 이 방식이었다면, 우유차님이 찾아낸 방법으로 찾을 수는 없었을 것입니다.
이게 대체 무슨 문제냐? 라고 말씀하시겠지만, 사용자들은 다양한 방법으로 크래킹을 시도하고 의외로 아주 단순한 곳에서 문제가 생기기 쉽습니다. 일반적으로 들어올 수 없는 URL을 추측하고 시도해서 그것을 통해 다른 사용자의 권한을 탈취하려는 시도를 하는 사용자가 있기 때문입니다. 이것을 막는 원시적인 방법으로 frame 태그 등으로 막기도 하고 있습니다.
이글루스 역시 같은 문제점에 봉착해 있다고 봅니다. 현재는 유료 서비스 부분도 적고, 권한을 탈취하려는 시도 역시 적은 듯으로 보입니다만(물론 아닐 수도 있습니다), 언젠가 마주칠 부분이라 보이고 언젠가는 그에 대한 대책이 있어야겠죠. 다음처럼, User Number를 암호화하거나, 또는 크래킹에 대해서 권한 체크 등을 확실히 하거나. (paranoia님의 덧글을 보고 추가 설명으로 남깁니다. User Number의 암호화는 필수가 아니라 선택입니다. 반대로 크래킹에 대해 권한 체크를 확실히 하는 것은 필수입니다)
그리고 여담입니다만, a/b 등으로 나뉘는 것은 그것을 키로 멤버쉽의 DB가 논리적, 물리적으로 분산되어 있는 것이 아닐까 하는 추측입니다. 그냥 추측이고, 맞다고 해도 온네트에서 가르쳐 줄리도 만무하겠습니다~!
마지막으로.
저도 참 심심한가 봅니다~!
'IT네트워크' 카테고리의 다른 글
| RealVNC 4.2 버전 업 쵝오! (6) | 2006.04.28 |
|---|---|
| 서비스는 통계를 낼 수 있는 권리를 갖고 있다. (3) | 2004.12.22 |
| 웹 광고, 보기 싫을 땐 보지 말자 (5) | 2004.12.02 |
| 이글루스에서 내 이름을 찾아봅시다. (5) | 2004.09.27 |
| 주민등록번호를 왜 요구하는가? (21) | 2004.09.12 |
