0255.txt

안녕하세요. 포프입니다.
오늘은
수염을, 아니 면도를 했어요.
아... 이전에
제가 보통 일주일에 한 번, 두 번 밖에 면도 안하거든요
귀찮아서
그런데 안하고 막 비디오 올리니까 사람들이
어디 아프신거 아니에요?
피곤해 보이세요.
난리를 쳐가지고
내가 포프TV 때문에 면도를 하는날이 오다니
어쨌든 그랬구요
오늘 할 얘기는
음...
보안 쪽에 대해서 이야기를...
그쪽을 이야기 좀 하려고 해요.
보안...
그...
보통 우리가 인터넷에
많은 개인정보를 놓자나요.
얼마전에
무슨 인터파크도 털렸다고 그러던데
털리면 왜 문제가 되냐
이런 여러가지를 얘기해 볼게요
일단은 문제가 되냐가 아니라
개발자 입장에서
과연 보안을 어떻게 해야되냐
그중에서도 특히
뭐... 여러가지가 있어요.
굉장히 다양한게 있는데
일단은 가장 중요한거는 이제
OWASP라고 [Open Web Application Security Project]
OWASP TOP10 이라고 검색하면
보통 웹사이트에서 TOP10으로 가장 문제가 있는
널리퍼진 그런 attack이라던가
그에 대한 해법이 나와있으니까
그걸 좀 보시길바라고
오늘은 그중에서도 특히 말하려고 하는게
과연
음...
굉장히 그 개인정보들
sensitive하다 그러죠
민감한 개인정보들을 어떻게 저장해야 올바른가
그거에 대해서 일단 얘기할게요
두가지 크게 얘기할거는
딱 오늘 두 개는 뭐냐면
하나는 해쉬하고
다른 하나는
음...
암호화
그러니까
encryption [암호화] decryption[복호화]
얘기를 하려고 해요.
일단 해쉬부터 얘기하려면
해쉬 함수는 누구나 아실꺼에요
어떤 데이터를 주면
그 데이터에서
뭐 가장 간단하게 이야기하면
그 정수값이  나오는 거에요
뭐 32bit라던가 64bit라던가 128bit
그리고 입력값이 언제나 똑같으면
해쉬값은 언제나 똑같아요
예를 들어서 제가  ABCD를 넣었다
근데 해쉬값이 64가 나왔어요
근데 나중에 ABCD를 또 넣어도
이 해쉬값은 언제나 64가 나와야 되는거에요.
그에 비해 이제 ABCDE을 넣으면
이게 64가 아니라 뭐 13000,
이렇게 나올수도 있는거고
해쉬의 재미있는 점은
이거는 수학적인 연산을 하는거거든요
어차피, 왜나하면 모든 캐릭터는
어차피 [정수] integer 값이니까 컴퓨터에선
그래서 [해쉬충돌] hash collision이 일어날 수도 있어요.
hash collision이 뭐냐면
ABC를 넣었을 때와
전혀 색다른
뭐... 글자 뭐 뭐 뭐 그냥 뭐
한국어로 바보바보
이렇게 넣는데 이 둘 다가 똑같이 해쉬코드로 만들면 64가 나올 수도 있는거에요
그래서 뭐 이거는 뭐
어떤 좋은 해쉬를 쓰냐 그런거의 문제인데
이 해쉬가 좋은점이 뭐냐
예를 들어서
제가 어떤 사이트의 비밀번호를 ABCD로 했어요.
근데 ABCD로 했는데
그거를 그 사이트에서
데이터베이스에 ABCD로 저장을 했으면
그 데이터베이스가 털리는 순간
제 암호코드는 들어나게 돼있어요.
그죠?
그리고 또 하나의 문제는
제가 ABCD를 쳐서 보냈는데
뭐 서버간에 통신을 하거나 뭐 그런 경우에
중간에서 가로챌 수 있다고 생각을 해봐요.
뭐 HTTPS가 아니라 HTTP라
그러면 그걸 보는 것 만으로도
아 얘는 비밀번호가 ABCD라는걸 아는거에요
해쉬를하면 장점은
그러니까 해쉬를 할 때에는
보통 시스템을 이렇게 만들어야되요
제가 ABCD를 넣었어요
처음 가입할 때 그러면
ABCD에 해쉬 알고리즘을 돌려서
그걸 64로 저장해 두는거에요
그쵸?
그러고 나중에 또 제가 로그인을 할 때
비밀번호 ABCD를 누르며는
서버 측에서 다시 해쉬코드 변환해서
변환된 값만 확인하고
같으면 같은 패스워드라고 간주하면 되요.
100%일순 없어요.
아까처럼 바보바보를 넣었을 때
AB, 그게 나올 수 도 있지만
뭐
그것도
그런일은 거의 드물다고 봐야죠
뭐 있긴해도 그게 큰 문제는 안되요
사실은
그래서 이렇게 ABCD, ABCD 넣는게 좋다
그러면 이제 제가 뭐 와이어(wire)에서
HTTP에서 제가 비밀번호 쳐가지고
web form에서 서버 갈 때는 ABCD로 가고
서버에 저장된거는
64로 저장이되죠
그러면 뭐 서버가 털려도
저는 문제가 없는게 정상이죠
원칙상은 그래요
근데 문제가 뭐냐면
이게 되게 재미있는건데
rainbow table이라는게 있어요
그게 뭐냐면
흔히 쓰는 해쉬 알고리즘이 있죠.
저희가 흔히 쓰는 무슨 뭐
FNV도 있고
무슨 뭐 .net의 기본 해쉬 [함수] function도 있을꺼고
뭐 굉장히 흔히 쓰는 해쉬 알고리즘이 있어요.
그걸 직접 만들지는 않고 대부분 그걸 써요
그러면 아까 말씀드렸듯이
ABCD를 넣으면
이거는 64가 나오는 거에요
그래서 해커들이 무엇을 만들어 놨나면
사람들이 가장 흔하게 쓰는
비밀번호들 있잖아요
뭐 ABCD, 뭐 나는 신이다, 뭐.. 뭐.. 뭐.. 뭐..
에이브릴 라빈하고 결혼할래요.
막 이런것들
아니면 뭐 ABCD1234
이런거를
해쉬로 만들어 놓은 그 테이블을 만들어 놓은거에요.
그러니까
ABCD를 넣으면 64
뭐 바보바보는 64
뭐 나는 누구랑 결혼할래요 그러면 뭐
이래서 테이블을 쭉 만들어 놓은거야
그래서 데이터베이스를 터는 순간
이 테이블과 비교하는 방식으로
이미 어떤 비밀번호를 넣었는지 알 수가 있어요.
그러면 이거에 대한 보안은 어떻게 하냐
매우 간단해요 salt하면 되요
salt가 뭐냐
아까 ABCD를 가져왔죠
그러면 이 뒤에다가
string을 더 붙이는 거야
무조건 정해진 string
underscore 하고 popeservice [ _popeservice]
그렇게 언제나 집어넣고 해쉬를 돌려요.
그러면 64가 아닌 다른 값이 나올꺼 아니에요?
그러면 나중에 또
로그인할때 누가 패스워드 넣었을 때도
ABCD가 왔죠?
그럼 _popeservice 붙인 다음에
해쉬를 돌리면 똑같은 값이 나와요.
이 중간에 붙이는 salt 값
이 salt 값은 아무한테도 알려주면 안되죠.
알려주면 문제가 있..
뭐 알려줘도 상관은 없는데
안들려주는게 좋죠. 그 rainbow table 안 만드려면
그래서
이런거는 이제 각
비밀로 저장해 놓고 서버에다가
그거를 해야되고
그리고 중요한 거는
처음 회원가입할 때랑
로그인할 때 언제나
똑같은 salt를 뿌려줘야 되요
그러면
패스워드 문제는 대부분 끝이나요
그러면 두 번째 문제
패스워드가 아니라
패스워드는 그렇게 저장하는 이유가
제가 패스워드를 다시
줄 필요가 없어요
사용자한테
너 패스워드 잃어버렸어?
그럼 리셋해버려
이거지
어! 너 패스워드 잃어버렸어?
니 패스워드는 이거야 라고
말해줄 필요가 없기 때문에 그렇게 하는거고
어느 서비스에서도
니 패스워드가 이거야라고 말하는데 있잖아요
걔내는 일단 sercurity가 개판으로 봐야되요
일단
그거를 plain text로 저장했거나
아니면 다른걸로 조금 있다가 얘기할
암호화를 해서 저장한건데
암호화에서 다시
원래 택스트로 돌릴 방법이 있다는 거 자체가
보안에서는 굉장히 문제가 많은거 거든요
그래서 그거 자체는 굉장히 노노 해요
그래서 그런 서비스가 있다면
일단 그 DB는 털릴거라고
가정을 하시고 하시면 되요
뭐 인터파크도 그랬던거 같아요
제 생각엔
그럼 두 번째
어떤 데이터들은
정보를 보여줘야되요
뭐 예를 들어서
중요한 정보를 중에 하나가 이제 뭐...
제 주민등록 번호 같은게 있다
그러면 주민등록 번호가 있고
나중에 무슨 주민등록번호를 확인하기 위해서
이거를 다시 보여줘야 되잖아요?
그러면 그냥 DB에 그냥 완벽하게
텍스트로 저장하는 방법이 있고
아니면 해쉬로 저장하면 원래 값을 못 불러오기 때문에
아까 말했듯이
여러 값이 하나의 해쉬값이 될 수 있다 했잖아요?
그거는 절대 안되고
이 경우에 쓰는게 암호화라는 거에요
암호화가 뭐냐
굉장히 단순한 거에요
우리, 일단 언어라고 보시면되요
어떤거냐면
제가 진짜 단순한 예를 들려드릴께요
예를 들어서
제가
음...
말도 안되는 단어를 하나 드리는 거에요
미 숫 빅이라고
그러니까 미 하면 미숫가루할 때 미숫있죠
그 미숫하고
그러니까 미는 [ㅁ]에다가 [ㅣ]
숫은 [ㅅ][ㅜ][ㅅ]
그러고 빅은 [ㅂ][ㅣ][ㄱ]으로
이걸 주고
이게 무슨 뜻인지 알아 맞춰라 하는거에요.
그럼
알 방법이 없잔아요 사실은
그럼 제가 하는 얘기는
아 이거를 풀려면
거기 들어간 자음들 있죠
[ㅁ] [ㅅ] [ㅂ] [ㄱ]
이거를
하나씩
자음 순서보면 가나다라 있잔아요
거기서 하나씩 오른쪽으로 옮기는 거에요
그러니까 [ㄴ]이었으면 [ㄷ]으로 옮기고
[ㄱ]이었으면 [ㄴ]으로 옮기고
그러면 제가 하려는 말이 뭔지 나와요
뭐 심심하신 분들은
풀어보고 그냥 댓글에 달아보세요
뭐 댓글이 좀 이상해질 것 같긴한데
요번
이것 때문에
그런 식으로 그냥 어떤
규칙을 정해 놓고
실제로 우리가 봐서는  뭔지 모르겟지만
아... 그런 알 수 없는 문자를 만들고
그리고 언제나 되돌릴 수 있는 그런
그러니까 수학적으로
암호화하는 방법
아까 이 방법으로 따지면 그냥
자음을 하나씩 왼쪽으로 옮기는게 암호화고
자음을 하나씩 오른쪽으로 암호화를 푸는 과정이죠
그래서 이런 과정이 있는데
뭐 이거는 굉장히 단순한 예 이고
실제 저희가
이제 암호화 이런 쪽에 쓰는 거는
여러가지 기법이 있어요
뭐... 뭐...
뭐가있더라
뭐 private public key라는 것도 있고
뭐 여러가지 방법이 있는데 자세히 들어가진 않을꺼고
결과적으로 모든
사용자 데이터
굉장히
좀 sensitive한 중요한 개인 정보들은
무조건 암호화를 하는게 맞아요
뭐 집주소, 전화번호
뭐... 이름
뭐...뭐... 자잘한거 다
왜냐하면 서버에 암호화가 되어있으면
그리고 이 암호를 푸는 키가 있거든요
뭐 수학적인 뭐 숫자죠
그걸 연산을 하면 나오는 거에요
그 키는 아무한테나 공개가 안되면
그 데이터는 볼 수가 있죠
언제든
근데 데이터를 봤을 때
재미있는거는
그거죠
이제 그 key가 털렸을 때
결국에는 이 데이터를 볼 수가 있어요
key도 털리고 DB도 털리면
그걸 다 복호화할 수 있고
복호환가?
복구할 수 있고
아니면 뭐
굉장히 컴퓨터로
엄청난 brute force 해갖고 할 수도 있어요
컴퓨터 파워만 엄청나게 많다면
그래도 그나마
뭐 지금 뭐 몇 비트로 암호화하느냐 얘기가 많은데
비트 수를 늘리면 늘릴 수록 그만큼
음...
깨기가 어렵죠
그리고 패스워드는 이미
깰 수가 없는거니까
아... 왜냐하면 이미
뭐라 그래
암호화 아니 해쉬를 만들었기 때문에
원상복구 못하는 거니까
그건 제일 중요한 information
나머지 것들은 털려도 좀 덜 털리는 information이에요.
완벽한건 없어요
모든 암호는 뚤릴 수 있고
언젠가는 뚤릴 수 있어요
그게 내부적으로 누가 뭐 key를 훔쳐서 뚫든
아니면 그냥 컴퓨터를 수천만대를 써서 뚫든
뚤순 있어요
안 뚤리는 암호는 없어요
그거를 점점 암호화를 강하게 해서 덜 뚤리게 할 뿐이죠
재미있는건 뭐냐면
아! 그러면 뭐든지 완벽한게 없는데
그러면 어떻게 하냐
뭐 중요한건 그거에요
자기가 죽어도 털리지 말아야되는 정보들은
안올리는게 맞아요 온라인에
그러나 털려도 좀 기분은 좀 나쁜데 어쩔 수 없다는 건
올리는 대신에 암호화를 강하게 해야죠
범죄 예방학에 보면
범죄 예방은 범죄를 안 일어나게 만드는게 아니에요
이게 정말 재미있는건데
범죄 예방학은 뭐냐면요
저말고
제 이웃이
집털리게 하는게 범죄 예방학이에요
이웃의 창문에는
창살이 없어
어 우리 집도 없어
그런데 난 창살을 달꺼야
그러면 도둑이 왔을 때
저보다는 이웃을 턴다
이게 중요한거거든요
보안도 굉장히 비슷해요
정말
제가 있는 기관이
매우 중요한 기관
뭐 정보부라던가 뭐 CIA, FBI
이런 곳이여서 사람들이
무조건 쳐들어오는 곳이 아니라면
그러면 보안을 사람들이 어떻게 해도
사람들이 쳐들어오겠죠
그냥 단순히 회사 입장이고
고객정보를 가지고 있는 회사라면
내 보안이 옆 회사 보다 나으면
옆 회사가 먼저 털리게 돼있는 거에요
저보다는
그게 재일 중요한 거에요
그래서 보안은 남들보다
떨어지지 않게
그리고 최소한 남들보다
좀 더 낫게 하는건데
OWASP라고 아까 말씀 드린거 있죠
그런데 가보시면 알겠지만
새상에 존재하는
엄청난 많은 웹사이트들이
개판이에요
정보를 plain text로 저장하는 경우도 많고
뭐
암호화를 대충하는 경우도 있고
뭐 패스워드를 암호화 하는 경우도 있고
그러면 상관
그러면 소용이 없어요
비암호화하면 나오기 때문에
그래서 그런 여러가지
얘들이 멍청한 짓을 하고있고
계속 그렇게 멍청한 짓을 할꺼에요
왜냐하면
결국 웹 개발하고
이렇게 서비스 개발하는 도중에
내 서비스가 커질지 안 커질지 모르면서
그거를 완벽하게 잡고 하는사람이 없어요
뭐 저 전에 다니던 회사에서도
신용카드 한번 털렸다는 그런 문제도 있었고
작은 회사 아니었는데
그래서 결과적으로는
이제
내가 남들보다 얼마나 좀 더 힘드냐
그 문제죠
그리고 이제 암호화 할 때
아~ 그러면 내가 현존하지 않는 암...
아! 현존하는 암호기법을 쓰면 누구나 뚫을 수 있다
그래서 새로운 나만의 암호기법을 만들자라는
얘기를 하는 사람도 있는데
대부분은 그러지 말라고 권해드리고 싶어요
일단
본인이 정말
미친 듯한 수학자가 아닌 이상은
이미 존재하는 암호화 기법보다
나은 걸 만들기도 어렵고
암호화 기법이 잘못되면
예를 들어서 1234가 있고
1235가 있어요
숫자가 1 증가한거죠
그 숫자가 1이 증가할 때 마다 암호패턴이 보이기도 해요
어떻게
그 encryption이 되는지
뭐 [exclusive or] XOR 같은거 하면 잘 보이겠죠
그런건
그래서 그런게 보이는 암호기법을 쓰면
뭐
쉽게
쉽게 털릴 수 있죠
쉽게 reverse engineering이 가능해요
그래서 그런거가 안되게 하기 위해서
존재하는
그 public encryption
뭐 OpenPGP
이런거부터 시작해서
뭐
이게 뭐 128bit냐 256bit냐
이런거도 나오는 거고
HTTPS도 뭐 그런 개념이죠 사실은
해서
그런거를 가능하면
쓰는게 좋아요
그런데 이제 또 그런걸 쓰는 동안에도
그런거 있잔아요
암호화는 이제하고 key 뒤에 따라
값이 달라지지만
아까 말 했듯이
숫자가 하나, 두 개 올라가는 것 따라
이게 패턴이 보일 수도 있거든요?
그럼 이런거에 대해서 어떻게
이렇게 방어를 하냐
이건 굉장히 재미있는 꼼수가 있어요
예를 들어서
제가
이제 encryption을 해요
string
plain text가
underscore 없이
그러니까 밑줄 없이
그냥 스트링으로만
이루어져있다고 생각해요
그러면 일단
예를 들어서 제가 ABCD를 받았어요
그쵸?
그러면 그 뒤에다가
아까 말했던 salt 같은거 있죠
그 정해진거 popeservice
_popeservice를 끼워요
그런데 여기서 끝나는 게 아니야
그 다음에
또 underscore하고
Random number를 하나 집어넣어요
숫자로
그러면 ABCE_popeservice_13250
뭐 이런식으로 나오겠죠
그러고 그냥 encryption 해버리는 거야
그러면 이게 데이터가 개판이지 않냐?
아니에요
encryption 한거는
decryption돌릴 수 있다고 했죠
그럼 decryption을 돌려요
그럼 똑같이 나오잖아요?
뭐 앞에 ABCD
popeservice
뭐 13000 어쩌구
까먹었어요
숫자
나오죠?
그러면
가져놨고
첫번째 string token만 가져다 쓰면 되요
그래서 이런식으로
salt하면서 random 값까지 놓았고
encryption되는 string이 좀 덜 보이게 하는 방법도
있어요
해서
제가
오늘 이렇게
말해야될 정도는 이 정도 인거 같아요
이 정도면
뭐
상당히 재미있는
뭐라 그럴까
웹사이트에서
왠만한
필요한
이 개인 정보 보호하는데
필요한
그런
데이터 저장
그리니까 이건 OWASP중에서
그냥
하나에 불과해요
그거에 대한 해결이 되죠
이러면 DB가 털려도
아 우리꺼 다 이제
뭐
패스워드는 저장 안해놨구요
다 해쉬 되어있으니까 걱정 안하셔도 되구요
개인 정보는 다 암호화 해놨어요
그리고 이 암호를 풀 수 있는 키는
딱 뭐 운영자만
운영자래...
뭐 사장만 가지고 있습니다 라던가
아무도 access가 불가능 하다 라던가
그런식으로 얘기를 하면
좀 고객들이 조금 더 안심하죠
재미있는거는
개발하는 사람들이
개발 편하려고 그런 키를
막 공유하고 쓰는 경우가 있어요
그런데 이제
그런거는 솔직한 얘기로
굉장히 소수에 사람만 가지고 있는게 맞아요
회사에서
정말
이 회사가 망하면 같이 망해야 되는 사람들?
그런 사람만 가지고 있어야지
이거를
아 직원들이 가지고 있다라는건
좀 문제가 되게 많아요
사실은
그래서
이제 그러면
이제 또 나중에 언젠가
한 뭐... 1, 2주 안에
말할 내용일 것 같은데
개발환경을 어떻게 설정하고
그런 key를 어떻게 보호하느냐에 따라
또 이게 바뀌거든요?
그래서
이
그냥
자기 스스로 서버 만들고
자기 스스로 서비스 하는 사람들은
회사가 정말 크지 않는 한 이런걸
잘 알기가 힘들어요
그래서 저는 차라리 클라우드 쪽이
좀 편하다고 생각하는데
요즘은
그런 부분에서
나중에 얘기하도록 하고
그래서 오늘은
또 원래부터 이 비디오를 만들려고 했는데
말도 안되게 인터파크가 털리는 바...
그... 바람에
왠지 흥할 것 같은 기분으로
아... 포프TV
음... 오늘은
아... 해쉬와 암호화
보안기법들에 대해서 말해봤습니다
예
포프였습니다.