안전한 비밀번호 만들기

유명인의 개인 휴대폰이 해킹당하면서 비밀번호 유출에 대한 논란이 일고 있다.
삼성전자는 "삼성 갤럭시폰이나 삼성 클라우드 서비스가 해킹을 당한 것은 아니다." 라고 밝히고 있다.

 

비밀번호 유출

대기업에서 운영하는 정보 서비스 자체 문제로 비밀번호가 유출되었다면 개인 한 두 명이 아닌, 대규모 개인정보 유출이 일어났을 것으로 필자는 추측한다. 아래 사례를 보면 기본 유출 정보는 1만명 이상이다.

(아래 링크를 클릭하면 해당 뉴스로 이동한다.)

 

• 2019년 12월. '페이스북 2억6000만명 개인정보 유출'

• 2019년 09월. '홈플러스 4만9천여명 개인정보 유출'

• 2019년 03월. '야놀자펜션앱 고객 정보 7만건 유출'

• ...

• 2011년 07월. '네이트⋅싸이월드 해킹사건'으로 3500만명 개인정보 유출

 

이번 비밀번호 유출 건은 개인의 비밀번호 설정에서 '유추가 가능한 비밀번호'를 설정했을 가능성이 높다.

필자가 추측하는 비밀번호 유출 경로는 아래와 같다.

 

• (가정) 피해자는 같은 비밀번호를 몇 년간 변경하지 않고 사용했으며, 비밀번호는 피해자 신상정보의 조합일 가능성이 있다. (예, ID+생일, ID+전화번호 등)

• (가정) 과거 다른 홈페이지에서 대규모 개인정보 유출 후 비밀번호를 변경하지 않았다.

 

여러 홈페이지에서 같은 비밀번호를 사용하면,

 

1. 규모 있는 홈페이지는 비밀번호 오류 횟수 초과 후 잠금상태가 되지만, 소규모 홈페이지는 이런 보안 장치가 없는 곳이 많다. 이런 소규모 홈페이지의 문제점을 이용하여 조합된 비밀번호를 계속 시도해 보는 것이 가능하다. 

2. 또한, 규모 있는 홈페이지는 기본적으로 비밀번호를 암호화하여 저장한다. 비밀번호가 ‘1234abc’일 경우, 서버에 저장될 때 암호화(예, ‘Qw1qdr4’ 이런식?) 되어 저장되고 로그인 시 입력된 비밀번호를 암호화하여 비교하는 방법이 있다. 소규모 홈페이지라면? 비밀번호를 그대로 저장할 가능성이 있다.

 

소규모 사이트에서는 자신이 평소 사용하는 비밀번호가 아닌, 새로운 비밀번호를 사용하고 책상이나 주변 어디엔가 적어 두는 수밖에 없다. 

---

아이폰 비밀번호 사례

2016년, 미국 FBI는 사망한 테러범의 아이폰 5c 잠금장치를 풀어 다음 테러정보를 얻고자 했다.

 

아이폰 5c는 2013년 9월 출시한 다수 컬러로 나온 최초의 아이폰이다. 플라스틱 재질로 충격과 생활흠집 내성이 강하다.

 

아이폰의 잠금장치를 풀기 위해 다음과 같은 제약사항이 있었다.

 

1. 애플사의 아이폰 암호는 대/소문자 알파벳과 숫자로 6자리를 조합(568억 개 조합 가능)할 수 있다.

2. 아이폰 보안체계에서 잠금 해제를 위한 암호 입력이5회 틀리면 1분, 9회 틀린 뒤에는 1시간을 기다린 뒤 다시 입력할 수 있다. 10회 틀리면 암호키가 지워져 올바른 비밀번호를 입력해도 잠금을 풀 수 없다.

3. 애플의 아이폰 암호 인식 시간을 12분의 1초가 걸리도록 하여 1초에 최대 입력 암호는 12개이다.

4. 이 때문에 모든 암호가 숫자로 이뤄졌을 경우 최대 입력 암호 개수는 100만 개로 (연속 입력 시) 22시간이 걸린다.

5. 알파벳 소문자가 조합돼 있다면 21억 7천만개로 늘어나 암호 해독에 (연속 입력 시) 5년 6개월이 걸린다.

6. 대문자 알파벳이 조합될 경우 568억개로 늘어나 (연속 입력 시) 144년이란 시간이 소요된다.

 

전문가들은 FBI가 테러범의 아이폰을 풀기 위해 '낸드 미러링(NAND mirroring)' 방식밖에 없다고 판단했다.

이 기법은 테러범 아이폰의 수많은 복사본을 만들어 각기 다른 암호를 입력 해 보는 것이다.

복사본에 10개의 비밀번호를 입력 해 보고, 비밀번호를 찾지 못하면 버리고 새로운 복사본에 비밀번호를 입력해 보는 것이다.

이 복사본을 10개, 100개로 늘려 입력 해 본다면? 비밀번호를 찾을 시간은 줄어드는 것이다.

 

결국 FBI가 외부에 100만달러 이상의 비용을 지불하고 숫자 4자리로 된 테러범의 비밀번호를 풀었다고 전해지지만 그 방법은 구체적으로 공개하지 않았다.

 

---

안전한 비밀번호 만들기

은행에서 통장을 만들면 사용할 비밀번호 4자리를 입력하라고 한다.

이 때 자신의 생년월일이나 전화번호, 유추하기 쉬운 번호(예, 0000, 1234 등)를 넣지마라고 한다.

왜냐하면 통장(또는 현금카드) 분실이나 누군가에 의해 도난당할 경우, 현금 인출 확률이 높아지기 때문이다.

 

아이디/비밀번호를 알면 누구나 아이디/비밀번호를 입력하여 인증이 가능한 한, 사실 안전한 비밀번호란 존재하지 않는다. (은행 ATM기에서 타인이 현금카드와 비밀번호로 현금 인출 가능한 것을 생각하면 된다)

단지, 유추하기(=풀기) 어려운 비밀번호를 만들어 해킹하기 어렵도록 하는 것이다.

여기에 아이폰처럼 시스템에서 입력 횟수나 시간 제약을 하는 방법으로 비밀번호를 해킹하는 시간을 늦출 수 있다.

 

안전한 비밀번호를 만드는 1단계는 복잡한 문자 배열을 만드는 것이다(예, 7i3q375h). 하지만, 사용자가 기억하기 힘들다.

 

한글을 사용하는 한국인은 다음과 같은 방법을 추천한다.

(한글을 창제하신 세종대왕님께 감사드립니다.)

 

1) 자신이 평소에 좋아하는 문구, 유행어, 시구절을 정한다.

단, 국어사전에 단어 설명이 되어 있는 것은 피한다. 예를 들어, '얼룩보금자리산세비에리아'라는 단어는 국립국어원 표준국어대사전에 단어로 설명되어 있다.

 

예> 별과 사람들

 

2) '특수문자'로 대체가능한 한글을 찾아본다..

 

예> *과 사람들 ('별'을 '*'로 대체)

 

 

3) '숫자'로 대체 가능한 한글을 찾아본다.

 

예> *과 4람들 ('사'를 '4'로 대체)

 

 

4) 자신이 기억하기 쉬운 비밀번호인지 확인한다.

 

 

5) 필요시, 비밀번호 앞 또는 뒤편에 '숫자'를 추가한다. 아니면, 해당 '홈페이지 이름'을 넣는 것도 좋다.

 

예> *과4람들네이버, *과4람들다음, ...

 

 

6) 만들어진 비밀번호를 영문자판으로 쳐 본다. 모바일은 영문 자판에 한글 표시가 되어 있는 키보드 사용을 권장한다.

 

예> *과4람들네이버 => *rhk4fkaemfspdlqj (비밀번호를 입력하면 영문으로 저장된다)

 

모바일도 한글이 표시 되는 영문 키보드가 있다. 검정색 알파벳 하단에 회색으로 한글 자모가 배치 되어 있다. 키를 누르면 영문이 입력 된다. (출처 : 더블 키보드)

 

자, 나만의 비밀번호가 만들어졌다. 외우기는 쉽고 풀기는 어려워 보이는가?

 

기본적으로 위와 같이 비밀번호를 만드는 것을 습관화하고, 2단계로 삼성전자에서 제시한 '휴대폰 인증'을 꼭! 해야 한다. 소규모 홈페이지는 '휴대폰 인증' 단계가 없을 가능성이 높기 때문이다.

 

무엇보다 카카오톡이나 문자 메시지로 온 링크는 함부로 열지 않는 것이 좋다. 해킹 프로그램이 설치 되고 사용자가 입력한 문자가 그대로 해커에게 전송될 수 있다. 키보드에서 입력하는 문자를 해커가 탈취할 수 있다면 비밀번호를 아무리 어렵게 만들어도 무용지물이기 때문이다.

 

---

비밀번호 관련 경험담

대규모 IT시스템을 만들 때 '올바르게 설계되고 프로그래밍되고 있는지?'에 관하여 감리 절차가 있다. 건축의 감리와 거의 동일하다.

 

건축물 입구에 위와 같은 '머릿돌(=준공표지판)'이 하나씩 있다. 여기에 시공자와 감리자를 기록한 것이 보인다. IT시스템도 위와 같이 서버실에 머릿돌을 만들어 놓으면 일하는데 좀 더 보람이 생기지 않을까? 서버실이 보안 구역이라 출입은 힘들겠지만 말이다.

 

다른 점은 IT 감리는 조율하는 과정이 있다. 건축 감리는 안전과 관계된 일이라 협상이 어렵지 않을까? 생각하지만 건축 쪽 관계자가 아니라 세부사항은 모른다.

 

건축주(=고객), 시공사 현장소장(=개발사의 필자) 그리고 감리자.

 

감리에서 프로그래밍 설계 상 큰 건으로 지적이 나오면 작은 건 여러 개와 맞바꾸는 경우가 있다. 어떻게든 감리 보고서(국회 청문회 보고서와 비슷하다)에 ’적정, 보통, 미흡, 부적정’ 중 ‘보통’ 이상이 나와야 한다.

 

한 번은 감리가 오픈 예정 시스템에 다음과 같이

"비밀번호의 자릿수를 8자리 이상으로 필수 입력토록 고치고 특수문자를 반드시 넣으시오! 그리고 3개월마다 고객이 비밀번호를 바꾸도록 하시오!"

라는 지적 사항이 나왔다. 보안 측면에서는 당연한 이야기다.

 

하지만, 개발사 입장에서는 오픈일에 맞추기 위해 밤샘하는 가운데 일이 더 늘어나게 된다. 감리의 짧은 의견이지만 입력된 비밀번호를 파싱 하여 비교하고, 이 비밀번호가 3개월 전에 생성되었는지 생성 당시 날짜를 저장하고 비교해야 한다. 좀 더 나가면 이전에 사용한 비밀번호를 또 사용하는지 비교해야 한다.

 

그렇다고 감리의 지적 사항에 맞서면 다른 더 큰 건으로 보복이 온다. 어차피 사람끼리 하는 일인데 감리의 감정 동요가 없을 수 없다.

 

필자는 다음과 같은 방법을 생각했다..

 

방법 1) 감리의 지적대로 시스템을 고친다. 빠듯한 개발 시간이 더 빠듯해진다..

방법 2) 이 건을 거부하고 다른 건으로 협상한다.

방법 3) 실사용 고객의 의견을 이용한다.

 

필자는 이야기했다.

 

"당연히 필요한 기능입니다만, 그러면, 고객들이 싫어할 겁니다.. 확인해 보세요."

 

사실 그 당시 사용 환경은 외부 인터넷과 연결되지 않는 조직 내부 시스템(=인트라넷)이라 사용자들은 매일매일 빨리 로그인하는 것을 선호했다.. 그리고 자신이 개인적으로 사용하는 비밀번호가 아닌 '1'이나 '2'와 같은 한자리 암호를 선호했다.. 보안상으로는 터무니없는 이야기지만 어쩌겠는가? 사용자가 선호하니...

 

결국 감리는 감리 보고서에 '패스워드 작성 요령' 만 보고서에 올리는 것으로 마무리되었다..

 

비밀번호 해킹/유출 뉴스를 접할 때마다 위 경험담이 생각난다.

---