양파맨의 겨울나기

• 패스워드의 생성규칙 가이드
  

  ---

패스워드 생성 시, 패스워드 생성 가이드를 제공하는 것이 과연 보안에 어느 정도나 도움이 될까? 그 규칙 중에 특수문자를 넣어야 한다고 "권장"하는 것은 어떤가? 얼핏 봤을 때, 비밀번호에 특수문자가 들어간다면 꽤 강력해 보인다. 실제로도 패스워드에 특수문자가 섞여있다면 꽤 강력한 패스워드이다.

그런데, 이 패스워드 생성규칙을 사용자가 강제로 따라야 한다면 어떨까? 가령

1. 패스워드는 8자 이상 12자 미만으로 이루어져야 합니다.
2. 패스워드에는 특수문자가 필수로 들어가야 합니다.
3. 아이디와 같은 문자열은 사용할 수 없습니다.

와 같은 조항들 말이다. 크래커가 패스워드를 알아내기 위해서 무차별대입 공격을 시작하려 한다. 그런데 업체에서 저런 규칙을 사용자에게 강제화 했다. 이로 인해서 어디부터 시작해야 할지 모르던 크래커는 작업이 더 쉬워졌다. 크래커는 자신이 만든 툴에 아래 규칙을 적용하였다.

1. 자릿수 8자리 이상 12자리 이하
2. 대입 시 특수문자를 필수로 입력. 예) votmdnjem! , votmdnjem!@, qlqjs!@#
3. 아이디와 같은 문자열은 제거

이제 패스워드에 특수문자가 포함되지 않은 문자열들과 13자리이상의 문자열들. 가령 votmdnjemqlalfqjsgh 와 같은 문자열은 무차별대입 공격 시에 제외된다. 매우 많은 경우의 수를 제거해 주는 것이다. votmdnjemqlalfqjsgh 대신에 votmdnjem! 와 같은 문자열을 넣어볼 테니 말이다. 왜 일부러 규칙을 강제화하여 많은 경우의 수를 제거해주는가?

1억 개나 1억 100백 개나 많은 건 많은 거고, 안전한 건 똑같이 안전한거다. 문자가 24개 이던 34개 이던, 어차피 숫자가 무한대에 수렴한다면 굳이 특수문자를 포함할 필요는 없다. 그렇다면 왜 소위 전문가들은 특수문자를 강제화하는 것에 이리도 적극적인가?

• 무차별 대입 공격과 사회공학
  

  ---

특수문자가 포함된 패스워드는 강력하다. 하지만, 이 강력함이라는 것은 무차별대입 공격(brute force)에나 강력한 방법이고, 키로거와 같은 악성코드가 설치된 PC라면 특수문자 할아버지가 들어간 패스워드 라고 해도 전혀 안전하지 않다.

현재의(2011년) 많은 인터넷 사이트들은 이 무차별대입 공격법에 어떻게 대응하고 있는가? 올바르지 않은 입력이 N 회 시도되면 접속차단 또는 캡챠와 같은 기술을 사용하여 자동공격을 차단하고 있다. 굳이 특문 포함이라는 극약 처방을 하지 않아도, 이런 방식으로 무차별대입 공격을 대부분 차단할 수 있다.

요즘 크래커들은 옛날과 같이 무식한 무차별대입법을 사용하여 일하지 않는다. 패스워드에 이름, 생년월일, 전화번호, 휴대전화번호 등과 같이 쉽게 알아낼 수 있는 여러 가지 정보들의 우선순위를 높여 대입해본다. 안되면 이들을 조합하여 넣어본다. 그리고 안되면 또 다른 방법을 사용한다. 가령 사회공학기법 같은. 그럼 100명 중에 적어도, 최소 한 명 이상은 걸린다. 열 명까지도 걸릴 수 있지 않을까 생각해본다. 운이 좋으면 30명도 걸릴 수 있지 않을까?

주제와는 조금 벗어나지만, 실제로 메신저로 돈 빌리기 사기나 전화피싱과 같은 사회공학기법에 낚이는 사람들이 많은 걸 보면 이게 어렵지 않다는 것을 어느 정도 유추할 수 있다. (약 10년 전에 세이클럽 계정이 털린 적이 있다. 세이클럽 디자인폼으로 메일이 도착했는데, 거기서 비밀번호를 묻기에 그냥 나도 모르게 입력해버렸다. 그리고 난 아바타 캐시를 털렸다.)

소위 전문가들은, 이런 사회공학기법들 때문에 특수문자가 필수로 들어가야 한다고 말한다. 사용자들이 유추하기 쉬운 패스워드를 사용하기 때문에 특수문자를 강제화하는 규칙을 넣는다는 것이다. 그러면 이런 상황에서 사용자들은 회원가입시에 어떤 행동을 취할까.

1. 자신이 자주 사용하는 비밀번호를 넣고 회원가입 버튼을 누른다.
2. 그럼 경고창이 뜨겠지. "특수문자가 필수임ㅋㅋ" 
3. 그렇게 되면 사용자는 짜증을 낸다.
4. 그리고 기존 비밀번호에 ! 또는 !@ 등을 추가해서 회원가입을 완료할 것이다.

안 그럴까? (평범한) 주변 사람 다섯 명을 불러놓고 테스트를 해보면 적어도 두 명은 이런 행동을 취할 거라 확신한다.

• 패스워드 생성규칙의 강제화
  

  ---

특수문자를 강제화 하는 것이 그리 안전하지 않다는 것은 그들도 잘 알고 있을 것이다.(아닌가?) 그럼 왜 관리자들은 패스워드를 강제화 하는 건가? 보안을 생각한 것도 물론 있겠지만, 더욱 큰 것은 아마 관리자 자신들의 심리적 안정감 때문 아닐까?

'사용자들에게 이렇게 시켰으니 적어도 1234와 같은 비밀번호를 사용하지 않겠지'
'유추하기 어려운 강력한(특문이 포함된) 패스워드이니 쉽게 깨지지 않겠지'
'난 보안을 지키기 위해서 최선을 다했어. 해킹 당해도 내책임 아님'

위와 같은 자기 위안들 말이다.

"소프트웨어 누가 이렇게 개떡같이 만들었어"라는 책이 있다. ( 원제목은 Why Software Sucks )
여기서 너무 많이 강화된 보안을 사용자들이 어떻게 생각하고 있는지 잘 이야기 해주고 있다. 외우기 어려운 패스워드를 메모지에 적어놓고 다닌다든가, 강화된 보안 시스템이 귀찮아서 문에다 벽돌을 받치고 누구나 쉽게 드나들 수 있도록 환경을 바꾼다든가 하는 그런 것들 말이다.

패스워드가 기억하기 어려워지거나 너무 자주 바뀌면 쪽지나, 스마트폰에 저장해두게 된다. 아니면 자신이 늘 사용하던 패스워드 한 글자를 특문으로 변경한다든가, 그냥 특문 하나를 더 붙일 뿐이다. 이런 강제적인 규칙들은 오히려 보안성을 떨어뜨릴 수도 있고, 최악에는 사용자들이 떨어져 나가게 된다.

사용성과 보안은 트레이드오프관계에 있다. 보안성을 높이면 사용성이 떨어지고, 사용성을 높이면 보안성이 떨어질 수밖에 없다. 이 둘의 관계를 잘 절충하여 모두 윈윈 할 방법이 요즘 조금씩 제안되고 있지만, 그래도 여전히 이런 불편을 완전히 없앨 수는 없다.

보안을 위해서 어느 정도 사용성 저하는 감수해야 하겠지만, 무턱대고 보안성만을 강조하여 사용자들을 불편하게 만드는 것은 한 번쯤 다시 생각해봐야 할 문제가 아닐까 한다.

"패스워드는 꼭 복잡성을 만족해야 한다." 정말 그런가? 적어도 규칙의 강제화는 답이 아니라고 생각한다.

클로저에 대한 설명은 어렵다. 어렵기 때문에 명확하게 이건 이거다 라고 이야기 하기 힘들다. 이야기 한다 해도 이해하기 위해서는 수많은 배경지식이 필요하다. 아무리 설명을 해봐야 사람들이 이미 알고 있던 부분들이 모두 다르기 때문에 설득을 해야 하는 수준이다. 인터넷에서 클로저에 대한 글들을 찾아봐도 모두 마찬가지이다.

모두가 이건 이거다 라고 설명을 하고 있지만 이해는 쉽지 않다. 자바스크립트에 이 클로저라는 녀석은 C언어에서 포인터를 배울때 만큼이나 날 혼란스럽게 한다. 이건가 싶으면 저거고, 저건가 싶으면 또 이것인 클로저를 잊지 않기 위해서라도 잠시 정리를 해둔다.

짧으면서도 설명하기 쉬운 아래 코드조각을 보자.

sayAlice() 를 실행하고, 리턴받은 함수를 또 바로 실행하고 있다. Step by Step 으로 확인해보자.

 
 

아래 단계를 따라가면서 조사식의 saylAlert 과 alice가 어떻게 변하는지 살펴보자. 

4번 단계가 실행 될 때, 내부의 alice 변수를 참조한다.
sayAlert 변수에 할당된 익명 함수가 선언된 다음에서야 alice 변수에 문자열이 할당 되었다. 이건 함수 내부에 선언된 함수 내부에서 부모함수(?)의 변수에 접근(참조) 할 수 있다는 것을 의미한다. 그리고 이 부분이 클로저가 만들어졌다고 볼 수 있다. 그리고 함수가 끝나서 지역변수들은 사라져야 함에도 불구하고 alice 지역변수는 계속하여 살아있는다. 클로저 때문이다.

좀 더 긴 예제인데, 간략하게 줄였다. 브라우저에서 실행하여 Step by Step 으로 보자.






여기서 6번이 중요포인트인데, 익명함수에 진입 할 때, num의 값이 40으로 확인 할 수 있다는 것이다. 기본적으로 num은 newClosure의 지역변수 이기 때문에 함수의 생명주기가 끝남과 동시에 소멸되어야 하는 변수이다. 하지만 클로저가 생성됨으로 인해서 이 변수는 그대로 살아있게 된다. 불필요한 메모리 릭을 방지하기 위하여, 이 변수를 사용한 뒤에 더이상 필요 없다는 판단이 들면 alert('num: ' + num); 문장 뒤에 num = null; 을 추가 시켜주자. 

인터넷익스플로러가 7 버전 까지 나왔을 때, 파이어폭스는 한창 강세를 보이고 있었다. 파이어폭스의 점유율을 의식하여 부랴부랴 7 버전을 내 놓았으니 말이다.

언제부터인가 IE6를 버리고 파이어폭스를 쓰기 시작했는데, 그 때가 아마 본격적으로 웹개발을 시작하고 얼마 안돼서였을거다. 당시 파이어폭스의 확장기능에 한창 매료 되어서 헤어나올 수가 없었다. 그중 단연 최고는 파이어버그 라는 개발자도구 였다.

원하는 곳의 DOM 구조를 바로 파악할 수 있고, 파일을 변경할 필요 없이 실시간으로 수정하며 적용된 모습을 볼 수 있었다. CSS 수정, 적용이 바로바로 가능했고, 페이지 로딩속도 및 HTTP status 코드는 물론이고, 자바스크립트 디버깅까지 지원하여 이게 없으면 개발이 불가능할 정도였다.

파이어폭스가 버전업데이트가 되어서 파이어버그가 동작하지 않으면 파이어폭스 업데이트를 미룰 정도였다. (나말고도 많은 사람들이 그랬을거다) 1.4 버전인지 1.5 버전까지 사용하고, 요즘엔 잘 사용하지 않고 있어서 어떻게 발전 하였는지 잘 모르겠다. 

파이어폭스에서는 제대로 개발을 할 수 없는 환경으로 터전을 옮기고 나서 IE 에서 돌아가는 여러가지 개발자도구를 찾아서 사용해보았다. 파이어버그에 비하면 턱없이 부족한 툴 들이었지만, 어쩔 수 없이 불편함을 감수하고 사용했다.

그러다가 IE8 버전이 나오고, 새로이 추가된 개발자 도구 라는 것을 보고 커다란 발전에 기쁨의 눈물을 흘렸었다.

Dom 셀렉터, CSS 선택수정, 중단점을 삽입할 수 있는 자바스크립트 디버깅, 콘솔창 추가로 개발환경이 무척이나 편리해졌다. 이는 IE9으로 오면서 더욱 강력해 졌는데, 이에 대해서 소개를 해볼까 한다. (자바스크립트와 콘솔 위주로 감)


콘솔창

인터넷익스플로러를 실행하고 F12 를 누르면 아래와 같은 개발자 도구가 열린다.

왼쪽 탭에는 HTML, CSS, 콘솔, 스크립트 등등이 있고, 이 선택에 따라서 오른쪽 탭 영역의 UI가 변경된다. 콘솔탭을 선택하면 빈 화면이 덩그러니 나타나는데, 맨 하단에 보면 뭔가를 입력할 수 있는 입력창이 존재한다.


여긴 자바스크립트나 기타 DOM객체를 직접 입력하여 확인해 볼 수 있는 공간이다. 실제로 사이트가 전부 로드된 상태에서 콘솔창에 관련 객체 이름을 써 넣기만 하면 그에 따른 정보가 출력된다.


테스트 페이지로 만든 곳의 this 객체 정보를 호출해봤다. 단지 this 라고만 입력했을 뿐인데, 현재 document의 this객체에 대한 정보가 나타난다.

테스트 페이지에 아래와 같은 HTML 태그를 추가했다.
그리고 콘솔창에서 위 엘리먼트에 대한 객체 정보를 호출해보았다.


표준 HTML DOM method인 getElementById() 를 사용하여 객체를 호출하거나, 그냥 ID 값만을 입력하여 객체에 대한 정보를 확인할 수 있다.

이 콘솔창에서는 다른 콘솔창과 마찬가지로 페이지에 설정된 자바스크립트를 실행시킬 수 있는데, 방법은 매우 간단하다.

 
위와 같은 자바스크립트 코드를 추가하고, 콘솔창에 함수 이름을 입력하면 바로 실행이 된다.

여기 콘솔창에서 사용할 수 있는 여러가지 내장함수들이 존재 하는데, 이는 IE8은 물론이고 웹킷, 모질라계열에서도 비슷한 동작을 한다.

window.console.log	console.log("로깅용 메시지")	로그 : 로깅용 메시지
window.console.error	console.error("에러 메시지")	: 에러 메시지
window.console.info	console.info("정보 메시지")	: 정보 메시지
window.console.warn	console.warn("경고 메시지")	: 경고 메시지
window.console.dir	console.dir(오브젝트)	오브젝트 내용이 출력
window.console.assert	console.assert(식, "메시지")	식이 틀릴 경우 메시지가 출력
window.console.clear	console.clear()	콘솔창의 내용을 모두 삭제함

콘솔창에서 사용할 수 있는 내장함수는 위와 같고, 각각 실행 하였을 때 나타나는 메시지 이다. 실제로 아래와 같은 코드를 작성하여 테스트를 해봤다.

결과창을 보면, 우리가 예상한 결과와 동일하게 출력된 모습을 볼 수 있다. console, 또는 window.console 이라고 입력하면 console에 포함된 메소드들이 출력되니 직접 입력해서 확인 해보자.

** 참고로 console.dir 은 IE9 에서 지원하는 신규메소드로 IE8에서 동작하지 않는다. console.dir(object); 로 실행 하며, 객체의 내용을 좀 더 상세하기 표현해 준다.

기존에 alert 과 document.write, iframe 등으로 디버깅을 하던 불편함은 콘솔창을 사용하면 말끔히 해결된다. 초반엔 익숙하지 않기 때문에 어색하겠지만 지속적으로 사용해보면 예전으로 다시 돌아가기 힘들어질 것이다. 

사용하지 않고 있던 사람들이라면 이번 기회에 한번 사용해보자. 이러한 콘솔창은 IE8 이상, 크롬, 사파리, 파이어폭스 에서 기본적으로 지원하고 있다.


2부. IE9으로 디버깅 하기 (2) - 자바스크립트 디버깅

IE9이 출시 되었습니다. 물론 꽤 오래전에 출시되었죠. 베타버전부터 사용중 이었고, 정식버전이 출시되기를 꽤 기다렸습니다. 기다렸던만큼 출시된 정식버전 IE9은 꽤 높은 완성도가 높았습니다.

기존에 있었지만 부각되지 않았던 기능들, 그리고 새롭게 추가된 기능들을 위주로 하여 IE9을 알아보겠습니다.

1. 주소창 검색

IE8에서 IE9으로 넘어오게 되면서 전반적인 UI가 변경되어 매우 심플해졌는데요, 가장 크게 변경된 부분은 주소창과 검색창의 통합입니다.

기존에는 웹사이트 주소를 입력하는 주소창과 검색을 담당하는 검색창이 분리되어 있었습니다. 기존에 검색창은 검색제안이나 비주얼서치 등의 새로운 기술을 내놓음에도 불구하고 접근성의 문제로 자주 쓰이지 않았죠.

 

이번 주소/검색창의 통합으로 검색제안이나 비주얼서치 등이 좀 더 부각되었으면 하는 바람입니다.
(링크 비주얼서치/검색제안 보러가기)

부가기능 갤러리에 가보시면 검색과 관련된 좀 더 많은 애드온들을 찾아 볼 수 있습니다. 한번 찾아가셔서 기존에 추가 되어 있는 Bing 이외에 구글이나 네이버등을 추가하여 좀 더 편리한 주소창 검색을 이용해보세요.
(링크 부가기능 갤러리 보러가기)

2. 사이트 고정 (1)

---

IE9은 아쉽게도 윈도우 XP 이하 에서는 제공되지 않습니다. 윈도우 비스타 SP1 이상에서 설치하여 사용할 수 있는데, 윈도우7을 사용중이라면 IE9과의 시너지 효과가 매우 커집니다.

IE9 에서는 사이트 고정이라는 새로운 기능을 내놓았는데요, 사이트를 주소표시줄에 고정시켜놓고, 필요할 때 마우스 원클릭으로 접속 할 수 있도록 하는 기능입니다.

윈도우7 시작표시줄에 joinsmsn 사이트를 고정시켰습니다. 파비콘이 아이콘이 되어 원클릭 접속이 가능합니다. 이는 기존에 사이트바로가기와 크게 다른 점은 없는데요, 나중에 설명드릴 사이트 점프 기능에서 차이점이 드러납니다.

사이트고정 기능으로 사이트에 접속하게 되면, 위 이미지에서 보이시는 것과 같이 이 창은 joinsmsn 을 위한 사이트 입니다. 라고 파비콘으로 표시를 해줍니다. 좀 더 깔끔한 모습을 원하신다면 파비콘의 크기를 64*64 사이즈로 변경해주세요.

고정방법은 여러가지가 있지만 가장 간단한건 고정시키고 싶은 사이트에 접속 한 뒤 그 사이트가 열려있는 탭을 작업표시줄로 잡아끄는 것 입니다.

작업표시줄에 등록이 되면 사이트의 파비콘이 아이콘이 되며, 사이트 접속시 고정된 사이트임을 알려주게 됩니다.

2. 사이트 고정 (2)
사이트를 고정하게 되면 보너스 기능을 하나 더 사용할 수 있습니다. 이건 웹사이트에서 지원을 해 주어야 하는 내용이지만, 지원만 된다면 서비스를 좀 더 편리하게 사용할 수 있습니다. 바로 점프리스트 기능입니다.

페이스북을 사이트 고정시켜놓고, 아이콘에서 오른쪽 버튼 혹은 왼쪽클릭 후 잡고 끌면 위와 같은 메뉴가 나타납니다. 페이스북 같은 경우는 뉴스나 메시지, 이벤트 등의 메뉴로 바로 갈 수 있고, 트위터나 위 이미지의 joinsmsn 에서도 기능을 제공하고 있습니다. 

IE8에서 웹슬라이스 라는 기능을 제공했었습니다. 신기능이지만 잘 사용하지 않는 기능중 하나죠. 개인적으로 이 기능도 웹슬라이스의 뒤를 따르지 않을까 걱정도 되지만 이런 기능들이 잘 활성화 되면 좀 더 웹을 편리하게 사용할 수 있을 텐데 말이죠. 기능의 활성화를 빌어봅니다.

조만간 사이트에 점프리스트 추가 하기를 포스팅 할 예정입니다. (매우 간단합니다.)

3. 보안 강화

MS에서 IE8 출시부터 강조했던 것이 하나 있는데, 바로 보안입니다. IE8 에서는 XSS필터, ClickJacking방지, 탭색변경, 스마트주소표시줄, 스마트스크린 등의 보안 기능을 대거 추가 하였고, 내부적으로 메모리 보호에 강화된 점을 내세웠죠. IE9 에서도 물론 보안 강화를 갖고 나왔습니다. 이미 IE8에서 웬만한건 추가 했기 때문에 특별한 것은 없고, 눈에 띄는 거라면 추적방지 기능과 엑티브액스 필터링 정도 입니다.

여기서 B라는 회사가 광고속에 삽입한 쿠키가 제 3사 쿠키입니다. (** 쿠키는 웹상에서 활동하는 정보를 갖고 있을 수 있는 일종의 임시파일 입니다.)

이러한 제 3사 쿠키의 활동을 막는 것이 추적방지기능 입니다. 이 추적방지 기능은 IE8에도 제3사쿠키방지 라는 옵션으로 제공되던 보안서비스이지만, 이를 좀 더 강화 했습니다.

아래 링크에 접속하여 외부 사이트에서 제공되는 블랙리스트 사이트를 IE9에 추가할 수 있습니다.
(링크 http://iegallery.com/kr/trackingprotectionlists/default.aspx)

의외로 제3사쿠키를 활용하는 사이트들이 많이 있습니다. 스스로도 개인정보 보호에 힘써주세요.

4. 자주 방문하는 사이트

about:blank 라는 문구가 낯이 익으신 분들은 저처럼 성격이 좀 급하신 분들 아닐까 합니다. 웹사이트의 시작페이지로 about:blank 를 넣으면 브라우저가 실행됨과 동시에 빈페이지가 뜨기 때문에 조금이나마 쾌적한 인터넷 환경을 만들 수 있습니다.

IE9 에서는 about:Tabs 라는 시작페이지를 공식적으로 지원하기 시작했습니다. 브라우저를 실행하면 방문했던 페이지들을 빈도수 별로 리스트업하여 보여줍니다.

 

어떤 브라우저 툴바에서도 비슷한 기능을 지원하는 것으로 알고 있는데요, IE9 에서는 자체적으로 지원하니 더이상 툴바에 의존하지 않아도 됩니다.


5. 성능
빠릅니다. 많이 빨라졌습니다. IE9 사용하시다가 IE8 이하 버전으로 못돌아갑니다. 자바스크립트 성능 향상이니, 뭐니 어려운 말 하지 않겠습니다. 설치하셔도 후회하지 않으실 겁니다. 은행권이나, 기타 대형 포털들에서도 무리없이 사용 가능하니, 망설이고 계시다면 한번 설치해보시는게 어떨까요.


6. 아쉬움
A. 확장기능
- IE9이 아무리 빨리지고, 보안성이 향상 되어도, 절대 안쓰는 사람들이 있습니다. 그 사람들이 꼽는 가장 큰 이유는 아무래도 확장기능 이 아닐까 합니다. 얼마 없기도 없을뿐더러 그나마도 찾기가 매우 어렵습니다. 윈도우모바일6.5 이하버전의 스마트폰을 사용하는 기분입니다.

아, 확장기능이 있기는 합니다. 다만 그 이름이 액티브엑스 라는게 문제지만요.

B. 부가기능
- 웹슬라이스나, 검색제안 등이 활성화가 안되는 것이 많이 아쉽습니다. 사용하기 어려운 것도 아니고, 만들기 어려운 것도 아닌데 의외로 많은 분들이 모르고, 쓰지 않습니다. 무엇이 문제일까요. 개발자스러운 접근방식? 검색제안 같은 것은 주소창과 검색창이 합쳐진 지금은 조금 기대가 됩니다만 웹슬라이스는 도무지 답이 없네요.

C. HTML5
- IE9의 특징 중 하나로 꼽는 것이 웹표준지원, HTML5의 지원 입니다. 하지만 이 지원 수준을 보면 참담합니다. 


다른건 봐야 머리만 아프니, 점수만 공개합니다. 일반 사용자야 브라우저를 사용하는데 HTML5 지원 미지원 여부가 뭐 그리 큰 차이겠냐만 개발자들에게는 참담합니다. 지원되지 않는 것들은 어떤 방식으로 구현을 해야 할지, 고민부터 앞섭니다. 

타 브라우저에 비해서 업데이트도 쉽지 않은데 말이죠.

7. 끝