패스워드 패턴화로 사이트마다 서로 다른 로그인 정보 사용

어제 회사에서 일하고 있는데 갑자기 학교 후배가 전화를 하더니 지금 네이트온을 쓰는중이냐고 했습니다. 우리 회사는 네이트온 접속을 차단하고 있기 때문에 네이트온에는 거의 접속을 안하고 그날 근무중이라서 당근 안쓰고 있었는데요.. 지금 내가 200만원을 네이트온으로 요구했다고 내가 한거 맞냐는겁니다..ㅎㅎ 드뎌 나한테도 이런 일이 생기는구나… 했습니다.

5분 후에는 태국에서 일하는 학교 선배가 국제전화로 전화를 해서 “나한테 반말로 200만원 달라고 한게 너 맞어?” 라고 했어요.. 일이 걷잡을 수 없이…ㅡㅡ; 급하게 아이폰으로 네이트온에 접속해서 (회사가 스마트폰을 통한 네이트 접속을 차단하지는 않았네요) 로그인해 있던 분들께 다 설명을 하고 네이트 패스워드를 바꿨습니다.

아무래도 3월에 있었던 네비게이션 업체의 개인정보 유출 사건으로 제 패스워드가 빠져나간것 같은데요.. 일반적으로 사용자 패스워드는 DB에 암호화해서 저장하는게 상식인데 도무지 이 업체는 패스워드를 평문으로 DB에 넣어놔서.. 이런 일이 생긴듯 합니다.

어쨌든 세상 사람들이 모두 착하다면 이런 일이 없겠지만.. 어쩔 수 없다면 사이트마다 패스워드를 다르게 해야 하는데, 사실 기억력에는 한계가 있기 때문에 사이트마다 수십 수백개의 다른 사이트의 패스워드를 다 기억하는건 불가능이죠.. 그래서 생각한게 “패스워드의 패턴화”인데요.. 다음과 같은 방식으로 패스워드를 패턴화 하는겁니다.

[KEYWORD] + $ + YY + [FIRST 2 LETTERS OF THE URL] + [THE LAST LETTER OF THE URL]

위의 패턴을 설명하자면

  • [KEYWORD]: 자기 자신만의 키워드
  • $: 특수문자
  • YY: 연도값
  • [FIRST 2 LETTERS OF THE URL]: 사이트 주소의 처음 2글자
  • [THE LAST LETTER OF THE URL]: 사이트 주소의 마지막 1글자

만약, 나만의 키워드가 blue 이고, 2010년에 네이버 사이트의 비밀번호를 설정한다면
blue$10nar
이렇게 되겠죠…

daum.net 이라면
blue$10dam

옥션이라면
blue$10aun

시간이 지남에 따라 연도값이 바뀌고, 나만의 키워드를 다른 단어로 교체하거나… 아니면 전혀 새로운 패턴을 만들어서 적용시킬 수도 있구요.. 이런 식으로 패스워드를 자신만의 패턴으로 쉽게 유추하도록 공식만 세워 두면 수많은 사이트의 패스워드를 일일이 기억할 필요도 없고 사이트마다 서로 다른 패스워드를 쓰기 때문에 개인 정보 유출 위험이 그만큼 감소되겠죠. 저는 이미 요즘 많이 쓰는 모든 사이트의 패스워드를 이렇게 패턴화시켜놨습니다. (그런데 네이버와 네이트 패스워드는 같다는…)

대부분의 사람들이 사이트에 가입할 때마다 동일한 ID+PW 조합을 쓰는데 이는 보안상 쥐약인건 다 알면서도 수많은 사이트의 인증 정보를 일일이 기억하지 못하기 때문에 위험성을 알면서도 그렇게 쓰죠..  제가 보기에 이건 쉬우면서도 꽤 괜찮은 방법 같은데.. 이런 방법 많이들 적용하셨으면 좋겠네요..

PS. 아이디어가 순식간에 떠올라서 패스워드 패턴화 서비스에 대한 특허를 생각해봤는데 특허 검색해보니 이미 2004년에 한 일본인이 국내에도 패스워드 패턴화에 대해 특허를 출원해서 2007년에 특허를 받았군요..;;

인터넷 대란 조선닷컴이 가장 먼저 보도?

조선닷컴이 접속 불능 상태에서 복구되자 마자 “사상 초유”의 인터넷 대란이 일어났다고 크게 기사를 냈는데..

2003년에 비해서 솔직히 사상 초유라고 할 수 있을지..
왠지.. 조선닷컴의 접속 불능은 우리 잘못이 아니라 해커가 해킹을 해서 그런거에요… 라고 변명을 하는듯 한 기사 제목처럼…. 살짝 그렇게 느껴진다…
사용자 삽입 이미지

이번 인터넷대란의 원인은 Slowris DDOS공격인듯…

오늘 2009년 7월 7일 네이버 메일을 비롯하여 청와대, 조선일보, 한나라당, 옥션 등 각 분야 1등이라고 할 수 있는 사이트들이 오후 6시~7시를 시작으로 접속 불가능한 현상이 6시간째 지속되고 있습니다.

이런 동시 다발적인 장애가 우연은 아닌것 같고.. 매우 상징적인 사이트들만 장애가 발생한 것으로 봐서 인위적인 공격에 의한 것 같습니다.

2~3주 전 아파치 웹서버가 DDOS에 취약점이 있다는 메일을 받았는데…
대략 내용은… 패킷을 천천히 보내면서 마치 정상적인 커넥션을 맺은 상태로 서버가 인식을 하게 한 상태에서..
미완성 HTTP헤더를 전송하는 방법으로 커넥션이 계속 대기 상태가 지속되게 하는 방법이라고 합니다.

아무래도 이전의 DDOS 공격과는 정 반대의 패턴으로 진행되는 공격에 별 힘도 써보지 못하고 그냥 무너지는것 같은 느낌이.. 2003년 인터넷 대란과 마찬가지로 이번 사태도… 7.7인터넷대란이란 이름으로 역사에 기록되지 않을까…–;




아래 글은 http://hackaday.com/2009/06/17/slowloris-http-denial-of-service/ 포스트 내용이고 그 아래는 제가 번역한 내용입니다.

[RSnake] has developed a denial of service technique that can take down servers more effectively. Traditionally, performing a denial of service attack entailed sending thousands of requests to a server, these requests needlessly tie up resources until the server fails. This repetitive attack requires the requests to happen in quick succession, and is usually a distributed effort. However, [RSnake]’s new technique has a client open several HTTP sessions and keeps them open for as long as possible. Most servers are configured to handle only a set number of connections; the infinite sessions prevent legitimate requests from being handled, shutting down the site. This vulnerability is present on webservers that use threading, such as Apache.


A positive side effect of the hack is that the server does not crash, only the HTTP server is affected. His example perl implementation, slowloris, is able to take down an average website using only one computer. Once the attack stops, the website will come back online immediately.

RSnake는 서버를 더 효과적으로 다운시킬 수 있는 DOS 공격 테크닉을 개발했다. 전통적으로 DOS 공격은 수천개의 request를 서버에 전송함으로서 진행했지만 이번 공격 방법에서는 서버가 죽을 때까지 서버의 리소스를 꽁꽁 묶어버린다. 이 반복적인 공격은 request가 짧은 순간에 연속적으로 보내져야 가능하며 보통 분산된 작업(여러 사람의 참여?)이 되어야 한다. 그러나 RSnake의 새 기법은 HTTP 세션을 일단 열어 놓고 가능한 오랜 시간동안 유지시키는 방법이다. 대부분의 서버는 설정상 제한된 수의 커넥션만 처리하도록 설정되었다. 이 “무한 세션”은 정상적인 request가 처리되는 것을 막고 해당 사이트를 다운시켜버린다. 아파치와 같이 쓰레드를 사용하는 웹서버의 경우 이 공격에 대해 취약점이 존재한다.

이 해킹의 긍정적인 side effect는 서버 자체를 다운시켜버리는 것이 아니라 HTTP 서버에 대해서만 영향을 가한다는 것이다. 이 기법에 대해 Perl로 작성한 예제인 slowloris 를 사용하면, 일반적인 웹사이트를 단 한대의 컴퓨터를 사용하여 다운시켜버릴 수 있다. 공격을 중단하면 해당 웹사이트는 즉각 정상으로 회복될 것이다.


번역문을 사용하려면 출처를 밝혀주시길


Slowris 관련 링크:
http://hackaday.com/2009/06/17/slowloris-http-denial-of-service/
http://ha.ckers.org/slowloris
http://isc.sans.org/diary.html?storyid=6622
공격코드 http://ha.ckers.org/slowloris/slowloris.pl