'강제'에 해당되는 글 2건

  1. 2011.04.19 패스워드는 복잡성을 만족해야 할까?
  2. 2010.08.09 그러니까, 태도의 문제인거다. 7
728x90
  • 패스워드의 생성규칙 가이드


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

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

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 )
여기서 너무 많이 강화된 보안을 사용자들이 어떻게 생각하고 있는지 잘 이야기 해주고 있다. 외우기 어려운 패스워드를 메모지에 적어놓고 다닌다든가, 강화된 보안 시스템이 귀찮아서 문에다 벽돌을 받치고 누구나 쉽게 드나들 수 있도록 환경을 바꾼다든가 하는 그런 것들 말이다.

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

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

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

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



혹시 같은 주제로 관심이 있는 사람이라면 아래 링크도 읽어보길 추천한다. 원문이 사라져서 복사본으로 대체한다.

복사본링크 : http://www.thechiefbaboon.com/forums/archive/index.php/t-17074.html
원문링크 : http://finance.yahoo.com/news/A-Strong-Password-Isnt-the-nytimes-3369144559.html


Posted by onionmen
728x90
솔직히 과장님이나, 팀장님이 그렇게 이야기 하고 지키라고 했으면 군소리 없이 했을 것이다. 하지만 입사한지 얼마 되지 않은 사람이 이렇게 해달라 저렇게 해달라 요구하면 쉽게 들어줄 수 있을까는 좀 다른 문제이다. 그것이 업무방식에 영향을 미칠 때 말이다.

과장, 팀장이라서 따르고, 신규입사자라서 안따르고 하는 것은 아니다.(물론 어느정도는 있겠지만) 회사의 분위기와 문화를 이해하고, 변경을 시도하면 충분히 공감하면서 변화를 수긍할 수 있다. 하지만 제대로된 말 도 없이 이런 변화를 받아들이라고 강요하면 반감부터 생기는 것이 사람이다.

게다가 이야기 하러 갔는데, 회사를 다녀도 이런 시스템은 없었다 라는 식으로 이야기를 한다면, 좋게 이야기 하고 싶지 않아질거다.

진정하고 조금만 생각해보자. 순수하게 업무적으로 생각한다면 내가 민감하게 반응한게 맞다. 하고자하는 내용은 논리적으로 문제없고, 어떻게 볼 때 효율성을 위해서는 더 좋다. 문제는 잘 알지도 못하는 사람이 바꾸자고 하는거다. 앞으로는 이렇게 해야한다. 라고 못박고 전혀 협상의 여지도 두지 않는다. 범용적인 것은 좋은데, 다른 부서들의 상황을 전혀 고려하지 않고 밀어붙인다는거다. 

필요한 정보가 이름, 주소, 주민번호라고 하자. 그런데 내가 알 수 있는건 이름과 주소 뿐이다. 그래서 이름과 주소를 적어서 냈다.

다음 상황을 보자.

A: "이름과 주소밖에 몰라서 그것만 적어서 냈어요."
O: "주민번호도 적어서 내셔야 하는데요."
A: "이름과 주소를 알면 주민번호는 그 쪽에서 알 수 있지 않나요?"
O: "이름과 주소를 알려주시면 주민번호를 알려드릴게요. 그거 적어서 내세요."
A: "그럼 다음번에도 이름과 주소를 알려드린 뒤에 주민번호를 받아서 여기 적은 다음에 다시 내야 하나요?"
O: "이미 한번 주민번호를 알려드렸잖아요. 그걸 기억하고 계셨다가 쓰셔야죠."
A: "왜 이렇게 하나요?"
O: "좀 더 확실하고 정확하게 하기 위해서 입니다."
A: "예전엔 이렇게 안하고 그냥 이름과 주소만 적어서 냈는데요?"
O: "예전 담당자는 이제 없으니 그렇게 못합니다.ㅋ"

예전에는 그냥 이름과 주소만 적어서 냈다. 그런데 이제 주민번호를 알아내서 적으라고 한다. 주민번호 물어봐서 적은 다음에 다시 낼 수 있다. 그런데 여기서 문제는, 알려준 정보로 얻어낸 주민번호가 정확한 주민번호인지 판단할 수 없다는 거다. 그냥 그 쪽에서 이거라고 던져준 주민번호를 써 넣어서 요청을 하는데, 이게 정확하다고 판단할 수 있는건가? 어차피 그쪽에서 알려준 주민번호인데 말이다. 이럴거면 무엇하러 주민번호를 요청해서 쓰나.

회사에는 이미 주민번호를 알고 있는 부서도 있고, 주민번호를 모르는 부서도 있다. 이미 알고 있는 부서는 문제가 안되겠지만, 모르는 부서는 이게 문제가 된다. 그럼 융통성 있게 해결할 자세를 보여야 하는거 아닌가?

아 답답하다.

말도 좀 부드럽게, 융통성 있게, 상황판단 해서 적절하게 하면 안될까? 
이왕 입사한거고, 함께 일을 해야 하니 적절한 선에서 타협해야겠지만, 앞으로 힘들어 질 것 같다.
Posted by onionmen
이전버튼 1 이전버튼

블로그 이미지
손을 따뜻하게 만들어 주고 싶은 애인이 있습니다.
onionmen

달력

 « |  » 2024.3
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
DNS Powered by DNSEver.com

최근에 올라온 글

Yesterday
Today
Total