패스워드 시스템 아이디어..
패스워드 시스템에 대한 아이디어가 하나 떠올라서 말이죠.. 일단 포스팅했던 글을 복사해놓겠습니다.
-----------------------------------------------------------------------------------------------------------------------
갑자기 떠오른 패스워드 보안 강화 솔루션 아이디어다. 그리하여 본인이 붙인 이름은 OTPES(One Time Password Exchange System). 뭔가 거창한 것 같지만 사실 굉장히 간단한 알고리즘을 가지고 있다. 일단은 이 아이디어를 까먹지 않기 위해 기록해둔다.
OTPES란 가장 이상적인 패스워드 방식인 OTP(One Time Password)의 진화된 버전 정도라고 생각하면 된다. OTP는 한번만 쓰고 버리는 패스워드이기 때문에 이미 사용한 패스워드를 공격자가 획득해도 소용이 없다. 패스워드를 안다해도 이미 그 시점에 패스워드는 바뀌어 있는 것이다. 실로 완벽한 패스워드 방식이라 할 수 있다. 하지만 OTP에도 단점은 있다. 관리와 통제가 매우 까다롭다는 것이다. 많은 분들이 사용하는 은행의 OTP만 봐도 알 수 있다. 패스워드를 알기 위해선 OTP 번호를 알 수 있는 작은 기계가 있어야 한다. 이 부분은 보안에 있어 큰 이슈가 생긴다.
무슨 이슈? 예를 들어 보겠다. 어떤 중요한 정보를 담은 컴퓨터가 있다고 하자. 이 컴퓨터에 대한 해킹을 방지하기 위해 방화벽, IPS 등 3중 4중의 대책을 마련해 놓았다고 가정하자. 만약 공격자가 컴퓨터의 하드디스크를 물리적으로 가져가버리면? 말짱 도루묵이다. 모든 해킹 중 가장 간단하고 효과적이지만, 가장 천대받고 있는 해킹이 1계층 해킹인 것이다. 현재 긍융권에서 사용중인 OTP는 그런 면에서 큰 위험에 노출되어 있다. OTPES의 가장 큰 장점은 1계층 해킹 즉, OTP 분실과 도난에서 자유로운 것이다. 일단 OTPES의 기본적인 개념을 살펴보자.
<그림>
OTPES는 OTP 시스템을 네트워크 상으로 옮겨놓은 시스템이다. 왼쪽의 사이트는 OTPES와 연동되는 고객 사이트이고 오른쪽은 고객 사이트를 관리하는 OTPES이다. 플로우를 확인하자.
1. OTP Generator에서 생성한 OTP들은 OTPES의 사용자 계정 DB에 분배된다
2. OTPES에서 생성된 OTP를 VPN을 통해 해당 사이트로 업데이트한다.
3. 사용자가 OTPES 클라이언트를 통해 로그인을 시도한다.
4. 로그인을 시도함과 동시에 1번~2번 과정을 다시 한번 수행한다.
5. OTPES 클라이언트는 OTPES DB의 계정과 패스워드를 이용해 사이트의 로그인을 수행한다.
즉, OTPES는 평소에는 1번~2번의 과정을 일정한 시간 간격을 두고 수행하다가, 사용자가 로그인을 시도하면 1번~5번의 과정을 수행함으로써 패스워드 보안강화를 꾀하는 솔루션이다. OTPES를 사용하면 다음의 장점을 기대할 수 있다.
1. 휴대용 OTP 장치가 필요없으므로 분실과 도난의 걱정이 없다.
2. 사용자는 OTPES 계정만 관리하며, 사용 사이트나 시스템에 대한 암호를 하나하나 기억할 필요가 없다.
3. 사용하는 방식이 OTP이므로 고객 사이트에 대한 패스워드 해킹이 불가능해진다.
4. VPN 장비만 있으면 시스템 구축이 가능하므로 비용이 저렴하다.
물론, 단점도 있다.
1. OTPES 시스템 자체가 뚫리면 관리하는 모든 사이트에 대한 보안이 깨진다.
2. 고객 사이트의 DB 시스템을 수정해야 하는 번거로움이 있다.
아직까진 장점이 더 많아 보인다. 문제는... 실제로 구축이나 실현이 가능할까 이지만 말야...
-----------------------------------------------------------------------------------------------------------------------
여기서 질문~!
1. 선생님께 이 아이디어를 말씀드렸더니 Kerberos와 흡사하다고 말씀하시더군요. Kerberos란 어떤 것이고, 이 아이디어와 비슷한 것인가요?
2. 실제적으로 구현 가능할까요?
3. 만약 실제적으로 구현 가능하다면, 어떤 기술에 대한 지식이 필요할까요? (C, C++, PHP 같은 것들..)
4. 예상하는 단점 외에 보안적인 관점에서 구멍은 없을까요?
갑자기 떠오른 아이디어지만 머릿속에서 떠나지 않아서 이렇게 글을 써봅니다.. 고수님들의 의견을 듣고 싶어요~
| 첨부 | 파일 크기 |
|---|---|
 OTPES.jpg | 156.42 KB |
악~ 이게모야~
중복되게 올려버렸네요.. 어떻게 지우죠? OTL
db password 해킹에 대한 예방책이라면
db password 해킹에 대한 예방책이라면
별로 메리트 없는 시스템 같아요..
mysql에서
select encrypt('1234') 하면 DES로 수많은 결과가 나와요
encrypt('1234')
h9hDYpsBfZHiA
encrypt('1234')
.AoLEPO6UfLfM
encrypt( '1234' )
lBwV4E.RBqCNA
encrypt('1234')
wBTATvMy5GZtg
랜럼으로 된 수를 ,, 입력한 패스워드를 key값으로 ,, 돌려서 나온거죠,,
select encrypt('1234', 'w//KndFR3k76Q')
select encrypt('1234', '.AoLEPO6UfLfM ')
select encrypt('1234', 'wBTATvMy5GZtg')
'1234'에 다른값이 오게되면 동일한 패스워드를 반납하지 않습니다
사용자가 만약 입력된 패스워드에 대한 검증을 하면 다 암호화된 원본을 반납합니다......
1234라는 패스워드에 대해서 여러가지의 결과가 나타나게 됩니다..
우리나라 DB의 패스워드가 ,,,평문은 말도 할것도 없고
md5나 sha1가 아닌 encrypt() 형태로만 보관되어도 유출되어도 크게 효과 없습니다..
db 패스워드 해킹방어가 목적이라면 일회용 패스워드보다,,,
동일한 패스워드에 여러가지 값이 나오는게
더 효과적일겁니다..
아...
그렇군요... 그런데 결국 패스워드 자체가 변하는 것은 아니니 키값이나 암호화 알고리즘을 알아냈을 경우엔 100% 뚫리게 되는 것 아닌가요? 만약 로그인시에 OTP Generator를 이용하여 패스워드 자체를 생성해서 사용하게 하면 키값이 알려진다 하더라도 다음 로그인시에 패스워드가 바뀌게 되니 소용이 없어지게 될 것 같은데... 움... 전문적인 지식없이 생각해본 것이라 모든 것이 안개속이네요... 참, 그리고 DB에 저장될 패스워드가 암호화 되는 것은 어차피 OTP를 이용한 패스워드 방식에서도 쓰일 수 있으니, 상호보완적인 관계같다는... 그래도 제가 전혀 생각하지 못했던 부분이네요! 감사합니다 ^^
Brute force 공격이면 몰라도 힘들지 않을가요?
사실 RSA같은 경우는 그 키값이 리만가설을 깨야지만 역함수를 찾아낼수 있습니다.
Brute force공격 이면 몰라도 역함수를 찾는다라 그건좀 힘들지 않을가요?
OTPES(One Time Password Exchange System)라고 말씀하신게 SSL과 차이점도 못느끼겠습니다.
제가 보기엔 원리는 둘다 비슷해 보이는데 말이죠 랜덤되는 키값이고 한번쓰고 버려지는;;
OTPES는 그걸 아이디에 대한 패스워드에 대한거고,, SSL은 패킷에 대한거죠
OPT를 사용하면서 OPT 단말기가 필요없다는 것이
OPT를 사용하면서 OPT 단말기가 필요없다는 것이 PC나 스마트폰에서 보안과 사용성을 적절히 조화시킨 아이디어로 보입니다.
글쓴이가 언급했듯이 OTPES 시스템 자체의 신뢰도가 이 시스템의 효용성을 좌우하겠군요.
왜냐하면 OTPES가 무너지면 나머지가 전부 무너짐으로 그 피해가 엄청나군요.
확률의 기댓값처럼, (문제가 발생할 확률 * 피해 정도)를 계산하면 약간의 확률에도 그 위험성은 매우 커지겠네요.
어차피 완벽하게 막을 수 없고, 늘 예상 밖의 일이 벌어지는 것이 현실입니다.
따라서 보안의 목표가 위험도를 최소한으로 낮추는 것이라고 한다면 이는 큰 단점으로 생각합니다.
게다가 필요한 시스템을 크게 나누어서 아래 3가지 있어야 하는데....
1) OTPES 시스템
2) 고객사 서버의 OTPES 모듈
3) 고객사 클라이언트의 OTPES 클라이언트 모듈
그 중에서 (2), (3)은 부가적인 고객사와 클라이언트가 설치해야 하는 것이네요.
(우리나라의 보안 시스템은 늘 내 PC에 뭔가 설치하기를 강요해서 이에 대한 거부감이 생기네요.)
여튼, 고민하는 모습이 좋아 보이네요.
건승하십시요.
내 블로그: http://unipro.tistory.com
감사합니다! 원래는 VPN 시스템만 있으면 구축
감사합니다! 원래는 VPN 시스템만 있으면 구축 가능할거라 생각했는데, 인증방식 자체가 바뀌는 것이라 전반적인 시스템 수정이 불가피하겠네요.. 하지만 만약 시스템이 제대로만 동작한다면 금융권과 같이 보안이 '생명'인 사이트에선 그러한 번거로움을 차치하고라도 사용할 가치가 있지 않을까요? ㅠ_ㅠ 새삼 이런 솔루션들 만들어내는 사람 대단하다 느끼네요..
1. 선생님께 이 아이디어를 말씀드렸더니
1. 선생님께 이 아이디어를 말씀드렸더니 Kerberos와 흡사하다고 말씀하시더군요. Kerberos란 어떤 것이고, 이 아이디어와 비슷한 것인가요?
- 네. 비슷합니다. Kerberos는 세션에 대해 인증하는 계념인데 반해 말씀하신 OTPES 는 사용자 식별에 사용 된다는 차이가 있겠네요.
Kerberos 는 세션 하이제킹 등에 대한 보안 용도로 쓰입니다.
2. 실제적으로 구현 가능할까요?
- 구현 가능하겠죠.
3. 만약 실제적으로 구현 가능하다면, 어떤 기술에 대한 지식이 필요할까요? (C, C++, PHP 같은 것들..)
- 암호화 기법. 언어별로 제공하는 암호화 기법이 서로 다른 내용이 아닙니다. 언어는 상관 없습니다.
4. 예상하는 단점 외에 보안적인 관점에서 구멍은 없을까요?
- OTP 방식이 소유기반의 인증방식이라고 할때, OTPES 역시 소유기반 인증방식입니다. OTPES 클라이언트등 특정 어플을 소유한 사용자가 인증 요청 할 수 있는 구조니까 말이죠.
또한 OTPES 클라이언트 사용권한에 대한 자체 인증이 추가로 들어가야 하는 구조다 보니, 더 번거로워 지면서 OTP 보다 높은 보안성을 제공 할 수 없습니다.
정곡을 찌르는...
사실 님께서 말씀하신 4번의 대답이 처음부터 마음에 걸리긴 했습니다.. 인증을 위한 인증이 필요한 부분이라 AIC 3요소 중 가용성 측면에서 큰 단점을 가지고 있지 않을까 생각했었죠. 만약 이 가용성에서 타격을 받는다면 '쓰기 편리하다'는 장점 중 하나가 사라져 버리니까요.. 어떻게 해결방법이 없을까요? ㅠ_ㅠ
단순히 가용성이 떨어지는 문제가 아니고, 사용하는
단순히 가용성이 떨어지는 문제가 아니고, 사용하는 의미가 없어집니다.
예를 들어 가용성/편의성을 포기하고 OTP 10개를 쓴다고 전체적인 보안성이 향상 되는 것은 아닙니다.
일반적으로 가용성/편의성과 보안성은 반비례 하지만, 그렇다고 언제나 반비례하는 건 아니죠.
인증을 위한 인증이 필요한 타당한 이유가 있다면 그렇게 해야 하겠지만,
기존의 OTP와 동일한 한계, 제약 사항이 있는데 굳이 저렇게 해야 할 합리적인 이유가 없어 보입니다.
OTP 생성기를 소지할 필요가 없다. -> 하지만 OTPES 가 설치된 PC 에서만 사용해야 한다.
OTPES 를 사용하려면 사용자 인증을 거쳐야 한다 -> 사용자 인증은 어떻게?? OTP로?
이런 식으로 2 factor 인증을 구현하는 건 적절하지 않아 보입니다.
가용성은 떨어지면서 결국 기존 인증 방식의 한계에서 벋어나지 못하기 때문에 사용해야 할 이유가 없게 되는 거죠.
결론적으로 OTPES는 특정한 어플리케이션만을 통한 인증 방식이 되는 건데, 이건 OTP 보다 보안성이 떨어지게 됩니다.