오늘:
1,195
어제:
3,568
전체:
3,251,522

자유게시판

?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부

415614_218130_4221.jpeg

 

"비밀번호가 도난되지 않은 상황에서 빈번하게 비밀번호를 바꾸면 비밀번호가 패턴화되고 추측하기 쉬워지거나 비밀번호를 어딘가에 적어야 하는 등 오히려 보안 위험이 될 수 있다"

 

비밀번호, 어떻게 관리하세요? 동일한 비밀번호를 사용하기도 하지만, 사이트마다 요구하는 조건이 각각 달라 여러 개를 쓰게 되죠. 특수문자를 섞어 설정해달라는 곳도 있고, 대·소문자와 숫자를 추가해라는 사이트도 있고. 또 이 모~든 걸 조합해 만들라는 엄격한 사이트도 있어요. 정말 복잡하죠.

 

그러다 보니 사이트의 비밀번호가 뭐였는지 까먹는 일이 많아요. "비밀번호가 틀렸습니다", "비밀번호를 다시 입력해 주세요" 이런 메시지를 보는 건 일상다반사예요. 비밀번호를 찾기 위해 인증 메일, 번호를 쓰는 일도 잦고요.

 

오늘은 하루에도 여러 번 입력하게 되는 이 "비밀번호"에 대해 얘기해볼까 해요. 찾아보니 우리가 몰랐던 썰이 많더라고요. 특히 당연하게 여겼던 "복잡한 비밀번호는 안전하다"가 사실이 아닌 걸 알게 됐어요.

 

1. "대소문자+숫자+특수문자=안전한 비밀번호" X

 

언젠가부터 비밀번호 설정 시 "특수문자"를 넣는 건 당연해졌어요. 회원가입 시 "특수문자를 사용하세요", "!,@,#,$,%를 포함한 비밀번호를 설정해 주세요"라는 메시지를 보는 게 흔해졌죠. 대부분의 웹사이트는 1개 이상의 특수문자를 섞어 쓰라고 권고하고 있어요. 이런 규칙이 적용된 시기는 2000년대부터였어요.

 

2003년 미국 국립표준기술연구소(NIST)는 "디지털 신원 지침"을 발표하면서 비밀번호에 대한 규칙을 규정했어요. 그중 하나가 "패스워드는 대문자, 소문자, 숫자, 특수문자를 각 하나 이상 포함해야 한다"였죠. 이 규칙은 미국을 포함한 기업·기관에 영향을 미쳤고, 우리나라 사이트들도 이 규칙을 적용하게 됐어요.

 

해당 문서를 작성한 사람은 당시 연구소에서 일하던 엔지니어 빌 버(Bill burr)였어요. 그는 4년 전인 2017년, 월스트리트저널(WSJ)과 인터뷰에서 충격적인 발언을 했어요. 특수문자를 포함한 비밀번호가 보안 수준을 높이는 데 별 도움이 되지 않는다는 거예요.

 

그는 해커가 비밀번호를 추측하기 어렵게 하기 위해서 이런 규칙을 만들었어요. 하지만 사람들은 그의 생각과 다르게 비밀번호를 구성했어요. 빌은 "pr0t3cT3d4!"로 복잡하게 섞어 사용하는 걸 바랐지만, "Monkey-1"과 같이 추론하기 쉬운 비밀번호를 만든 거예요. 보안 강화에는 전혀 효과가 없었죠.

 

가장 많이 사용하는 암호는 다음과 같다.

Password-1234 / Br0nc0$2012 / Password123$ / Password1234 / Summ3rSun2020! / 0rlando_0000 / Password1234! / ChangeIt123 / 1234password$ / ChangeItN0w! / admin / 12345 / 123456 / 123456789 / qwerqwer / default / password / root

 

괜히 사용자의 부담만 높이는 셈이 된 거예요. 게다가 비밀번호를 외우지 못하는 사용자가 메모장이나 다른 형태에 로그인 정보를 보관하게 됐고 이를 탈취당하는 일까지 생겼어요.

 

빌은 인터뷰에서 많은 이들의 불편과 시간 낭비를 유발했다면서 “내가 했던 일을 많이 후회한다”라고 사과했어요.

 

 

2. 자주 바꿔야지 안전한 비밀번호일까?

 

"개인 정보 보호를 위해 비밀번호를 변경해 주세요"

 

오랜만에 방문한 사이트에 로그인하면 이런 메시지를 볼 수 있어요. 이 규칙 역시 NIST에서 발표한 "디지털 신원 지침"에 포함된 내용이었어요. 45~90일마다 정기적으로 비밀번호를 바꾸는 것. 비밀번호를 바꾸지 않고 오랫동안 사용할 경우 유출·해커의 무차별 대입 공격 가능성이 높다는 게 그 이유였죠.

 

하지만 몇 년 뒤 NIST는 관련 규칙을 변경했어요. 정기적인 비밀번호 변경이 아닌, “해킹 당했다고 생각할 때만 비밀번호를 변경해라"라는 거였죠. NIST는 잦은 변경이 오히려 사용자가 여러 도메인에서 사용하는 비밀번호를 기억하기 어렵게 만든다면서 “보안 효과 저해를 초래한다"라고 언급했어요.

 

실제로 관련 연구결과도 나온 바 있어요. 노스 캘리포니아 대학교 연구진은 "비밀번호 만기일에 대한 보안연구"를 진행했어요. 연구 방식은 다음과 같았어요.

 

1) 연구진은 3개월마다 비밀번호를 변경하도록 강제된 10,000개의 계정 정보를 확보했어요.

    (계정은 과거 학교 학생, 학사 행정직이 사용했던 것!)

 

2) 계정 이용자가 이전에 변경했던 비밀번호 이력 몇 개(약 4~15개)도 제공받았어요.

   연구진이 총 제공받은 비밀번호는 5만 1000여 개 정도였죠.

 

3) 연구진은 비밀번호를 추측할 수 있는 "해독 도구"를 사용해 비밀번호를 알아내는 과정을 반복했어요.

 

4) 수개월간 작업을 반복한 결과, 연구진은 약 60%의 비밀번호를 해독할 수 있었어요.

 

비밀번호를 어떻게 알아낸 걸까요? 연구진은 변경된 비밀번호에는 규칙이 있다고 설명했어요. 새로운 비밀번호를 예전에 사용했던 비밀번호와 비슷하게 만든다는 거죠. S,$처럼 글자와 유사하게 보이는 기호로 변경하거나, 숫자의 순서를 바꾸고, 특수기호 위치를 앞뒤로 바꾸는 것처럼요. 연구진은 약 17% 계정은 5회 이하 추측으로 비밀번호를 해독할 수 있었다고 설명했어요.

 

자주 변경하더라도 쉽게 예측될 수 있는 형태로 단순하게 조합하니, 정기적으로 변경할 필요가 없는 거예요. 앞선 특수문자와 같은 이유였죠. 이 때문에 NIST는 "주기적 변경 사용" 규칙을 철회했어요.

 

 

3. 안전한 비밀번호는? 말도 안 되는 긴~ 문장

 

그럼 대체 안전한 비밀번호는 뭘까요?

 

미국 연방수사국(FBI)은 "패스프레이즈(Passphrase)"를 사용하는 걸 추천했어요. 패스프레이즈는 여러 단어를 섞어 만든 비밀번호를 말해요. "VoiceProtected2020WeAre"처럼 연관성 없는 단어를 붙인 형태라고 보면 돼요. 예를 들어 "Tr0d4dor&3"와 같이 복잡한 비밀번호보다는 "DirectorMonthLearnTruck"처럼 어울리지 않은 여러 단어를 섞은 게 더 낫다는 거죠.

 

왜일까요? FBI는 복잡성보다 길이가 중요하다고 강조했어요. 짧고 어려운 비밀번호보다 15자 이상의 긴 비밀번호가 해독하기 더 어렵다는 거예요. NIST 역시 해커는 비밀번호 길이가 길수록 암호를 푸는 데 더 큰 노력을 기울여야 한다고 설명했어요. 조합할 경우의 수가 늘어나면서 알아내기가 힘겹다는 거죠.

 

 

4. 해커는 어떻게 비밀번호를 탈취할까?

 

해커들이 비밀번호를 탈취하는 방법은 여러 가지예요. 대표적인 건 "스팸 메일(Spam mail)", "피싱 사이트(Phishing site)"가 있죠.

 

다들 알다시피 스팸 메일은 "급박한 소식인 척" 하면서 사용자의 클릭을 유도해요. “당신이 내 저작권을 침해했다!”라거나, 경찰청을 사칭해 사용자가 클릭할 수밖에 없게 만들죠. 이렇게 출처가 불분명한 메일을 열 경우, 피싱 사이트에 접속할 확률이 높아요.

 

피싱 사이트는 정보를 꺼내기 위해 홈페이지를 모방해 만든 가짜 홈페이지를 말해요. 로그인 정보를 탈취하기 위해 만들어진 사이트인데, URL을 보기 전까지는 평범한 로그인 창이라 구분이 어려워요. 메일뿐만 아니라 문자, 카카오톡으로도 이런 링크가 온다고 해요.

 

최근에는 중X나라를 통한 거래에서도 비슷한 피해가 발생한 바 있어요. 네이버 페이로 결제를 유도하면서 해킹 URL을 전송해 계정 정보를 입력하게 만든 거죠. 또 가상화폐 거래소를 위장해 로그인을 하게끔 만드는 경우도 있어요.

 

공용 PC를 통한 유출 사례도 많아요. PC방이나 도서관처럼 하나의 PC를 여러 명이 사용할 수 있는 환경의 경우 로그아웃을 꼭 해야 해요. PC가 악성 프로그램에 감염됐을 경우 비밀번호가 유출될 확률이 높아요.

 

동일한 아이디, 비밀번호를 타 사이트에서도 사용할 경우도 위험해요. 보안이 허술한 사이트에서 피해가 발생할 경우, 계정 정보가 한 번에 다 탈취될 수 있어요. 사이트별로 비밀번호를 각기 다르게 설정해두는 게 좋겠죠.

 

 

5. 계정이 털리지 않으려면..."2단계 인증" 설정해두기

 

요즘은 보안을 위해 이중 보안 서비스를 적용하는 사이트가 많아요. 회원이 평소 사용하지 않던 기기, 다른 IP에서 접속했을 경우, “정말로 당신이 맞나요…?”처럼 한 번 더 확인 단계를 거치는 거죠. 이를 "2단계 인증"이라고 해요.

 

네이버로 예를 들어볼게요. 네이버는 평소와 다른 환경에서 로그인됐을 때, 앱으로 알려줘요. "새로운 환경에서 로그인되었습니다"라는 메시지와 함께 인증 요청 메시지를 보내죠. 만약 이 인증 과정을 통과하지 못하면 서비스를 이용할 수 없어요.

 

다음이나 구글, 트위터, 슬랙, 마이크로소프트도 모두 2단계 인증을 사용하고 있어요. 물론 사이트 별로 방식은 다 달라요. 개인 휴대폰·이메일로 전송된 코드를 입력해야 하거나, 전용 앱을 통해 "확인" 버튼을 눌러야 하는 경우도 있죠.

 

보안을 위해서는 2단계 인증을 걸어두는 게 좋아요. 구글플레이스토어에서 동의 없이 결제가 되는 피해는 이 "2단계 인증"을 해두지 않아서예요. 개인 정보나 동의 없는 결제를 막기 위해선 꼭 필요한 단계라고 볼 수 있어요. 현재 이용하는 사이트에서 2단계 인증을 지원하고 있다면 꼭 설정해서 미리 대비하면 좋겠죠~

 

 

6. 정보자산의 보안 강화를 위하여 2단계 인증(2차 인증, 추가 인증)을 도입해야 하는 이유

 

"정보자산의 로그인-ID/비밀번호가 유출이 되어도 대안이 있느냐?"

 

1) 보안 강화를 위하여 사용자 식별ㆍ인증을 위한 OTP 등을 활용한 2단계 인증체계 적용

 

가장 중용한 것은 정보자산의 보안 강화를 위하여 "사용자 식별.인증을 위한 OTP 등을 활용한 2단계 인증체계를 설정"하는 거죠.

 

2단계 인증은 정보자산에 로그인 시 아이디/비밀번호 외에 도 추가적인 인증(2차 인증) 수단을 이용하기 때문에 단순히 계정 정보가 유출된 것만으로는 공격자는 이를 악용할 수 없죠.

 

2차 인증 적용(예: ID/PW + OTP), 일정 횟수(예: 5회) 이상 인증 실패 시 접속 차단 및 인증수단을 특정하지는 않고 있으나, 지식기반.소유기반.특정기반 인증 수단 중 서로 다른 방식에 속하는 인증수단 2개를 조합해서 사용해야죠.

 

2) 악의적인 목적으로 만들어진 프로그램인 악성코드에 의한 불법적인 우회/원격접속을 차단

 

악의적인 목적으로 만들어진 프로그램인 악성코드 프로그램에 의하여 정보자산의 접속정보(Desktop to Application, Desktop to Desktop, Desktop to Server, Desktop to Database,Server to Server 등)를 불법 취득한 뒤 불법적으로 정보자산에 우회/원격으로 접속하는 것을 차단 해야죠.

 

3) 분실.도용.해킹으로 인한 사용자 비밀번호 초기화에 적용

 

사용자 본인 스스로 로그인-ID, 특정항목, 일회용 인증키를 입력하여 맞으면 새로운 비밀번호를 등록하여 사용하게 해야죠.

 

보안 사고는 이제 삶의 일부가 되어버렸다. 온갖 보안 수칙들이 등장하고 보호 기술들이 나오고 있지만 아직 사이버 공격과 보안 사고로부터 완전한 면역력을 갖춘 조직은 하나도 없다. 오히려 디지털 데이터에 대한 의존도가 높아지고 원격 근무 체제가 확산되면서 사이버 공격의 위험에 더 크게 노출된 상태다.

 

 

"아무 것도 하지 않으면 중간은 간다"는 건 오래된 말이고, 클라우드 시대에는 통하지 않는 말이다. 새로운 시대에는 새로운 보호 장치가 어울린다. 비밀번호 하나로 관문을 지키는 건 더 오래된 방식이다. 시스템과 인프라는 자꾸만 새 것으로 바뀌는데 왜 예전 것들을 부여잡고 있는지 각자가 스스로를 검토해야 할 때죠.


List of Articles
번호 제목 추천 수 글쓴이 날짜 조회 수
1929 "8자리 숫자 푸는데 단 37초" 충격…내 '비밀번호'도 뚫린다 file 0 BaroPAM 2024.08.27 408
1928 [무료 세미나] [BICG] 실제 광고 이미지 만들기 0 인공지능팩토리1 2024.08.26 140
1927 [2024년 DPG AI Challenge 경진대회] file 0 인공지능팩토리1 2024.08.26 153
1926 Firefox 엔진 기반의 Arc와 비슷한 오픈소스 브라우저 Zen 브라우저! 2 0 하늘구름 2024.08.24 332
1925 [무료 세미나] [BICG] 자연스러운 AI 0 인공지능팩토리1 2024.08.20 194
1924 [BICG] 100만 버튜버시대, 당신의 친구도 버튜버일 수 있다 0 인공지능팩토리1 2024.08.19 203
1923 [BICG] AI 생성물 상업적 사용을 위한 토론 - 저작권, 초상권 중심으로 0 인공지능팩토리1 2024.08.19 133
1922 한글 베타가 구름 OS에서 다운되질 않군요; 2 0 Angry.Nerd 2024.08.19 377
1921 다계층 보안레벨의 인증 솔루션으로 클라우드의 정보자산 보호 file 0 BaroPAM 2024.08.18 164
1920 [한컴아카데미] NVIDIA AI Academy 교육생 모집(6개월 960시간 _ 무료교육) file 0 한컴아카데미 2024.08.14 129
1919 [2024년 Gemma 파인튜닝톤] 0 인공지능팩토리1 2024.08.13 155
1918 [BICG] 인스타툰으로 인플루언서의 일상을 공개하는 방법 0 인공지능팩토리1 2024.08.13 153
1917 [리눅스] COSMIC 새 데스크톱 환경 알파 빌드 공개 1 0 하늘구름 2024.08.12 228
1916 [BICG] 픽셀데이터에서 잠재적 모델로의 확산 0 인공지능팩토리1 2024.08.12 117
1915 서버리스 인프라 취약점을 악용하는 사이버 공격 증가 file 0 BaroPAM 2024.08.11 181
1914 올림픽 생각보단 잘했네요 ㅎ 0 민트야야 2024.08.06 206
1913 [BICG] Midjourney Cref/Sref seed를 이용한 AI 인플루언서 제작방법 0 인공지능팩토리1 2024.08.06 155
1912 디시발 ㄹㅇ 감기 빨리 낫는 법....jpg file 0 eeetttt 2024.08.06 389
1911 [NVIDIA AI ACADEMY] 4기 모집 안내 file 0 한컴아카데미 2024.08.05 147
1910 [BICG] ComfyUI 와 soylab 인플루언서 Viki 0 인공지능팩토리1 2024.08.05 126
Board Pagination Prev 1 2 3 4 5 6 7 8 9 10 ... 102 Next
/ 102
CLOSE